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

[ayers at gcc dot gnu dot org]

------- Comment #6 from ayers at gcc dot gnu dot org  2009-03-16 23:51 -------
I've played a bit with creating a trivial static library and linking into an
dynamic library and into an executable.  After tweaking back and forth it seems
that at least on GNU/Linux the static version linked into the executable
actually replaces the version that was linked into the dynamic library... not
sure what would happen if the version linked in last doesn't satisfy all the
requirements needed by the dynamic library.

All very intriguing , yet I believe it has nothing to do with your issue.

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) I went ahead and
updated an old Windows VM, installed all kinds of updates... and then installed
MinGW/MSYS natively.  First I reproduced you issue successfully and then went
about installing GNUstep.  Note that GNUstep's MinGW HOWTO explicitly states:

"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.  ..."

After installing the GNUstep packages, I was able to build and execute
applications.  Now GNUstep uses it's own build environment (gnustep-make) to
hide all the fancy stuff that needs to be done on windows.  I was hoping to see
something with messages=yes to give me an indication of what you need to do.
Yet I had no luck in identifying anything interesting.  Well except that
GNUstep is using a shared libobjc.

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.

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.


-- 


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