[Bug libobjc/39465] libobjc does not find classes of DLLs

js-gcc at webkeks dot org gcc-bugzilla@gcc.gnu.org
Tue Mar 17 14:05:00 GMT 2009



------- Comment #7 from js-gcc at webkeks dot org  2009-03-17 14:05 -------
> Since I wasn't able to get a cross tool chain running (and www.mingw.org
> doesn't seem to support that with the current gcc versions)

Please have a look at the Portfiles I gave you a link to, they include all the
stuff you need to know to build mingw32 with gccc 4.3 as a crosscompiler ;).

> "It's a good idea to remove the libobjc.a and libobjc.la and
> include/objc headers that come with gcc (gcc -v for location) so that
> they are not accidentally found instead of the libobjc DLL that you
> will compile below.  ..."

Yeah, that's exactly what Nicola Pero told me. The default is that there's only
a libobjc.a on Win32, but that doesn't work. So GNUstep lets you compile a
libobjc.dll and if you use that instead, it works.

> Well except that
> GNUstep is using a shared libobjc.

Yeah, that should already do the trick.

> I'm going to throw in the towel here, but I don't believe your issue has to do
> with libobjc.  I think your missing some flag or extra processing that
> gnustep-make might do for you dll or the program.

That's what I thought first, too. But after talking to several GNUstep
developers on FOSDEM, none of them was aware of any extra flags. They said all
they did was recompile libobjc as a DLL and then it would work.

I haven't seen any DllMain() in libobjc yet (though I have to admit I haven't
really looked for it, only had a few libobjc sources open in the editor for
various reasons, but never to look for DllMain), but it might be possible that
there is some initialization code in DllMain() of libobjc.dll that does some
initializing stuff that fixes it.

> But I also believe that statically linking (potentially different versions) of
> libobjc into different modules is error prone.  I guess it would be OK, if you
> only have a single executable, but the constellation of the dll linking one
> version and the executable potentially linking another scares me... even if
> that itself is most likely not your issue either.

I think the DLLs don't link to the static version of libobjc - at least, I hope
so, as that'd be useless.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465



More information about the Gcc-bugs mailing list