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

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

[ktietz at gcc dot gnu.org]

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktietz at gcc dot gnu.org

--- Comment #16 from Kai Tietz <ktietz at gcc dot gnu.org> 2010-10-29 14:12:26 UTC ---
(In reply to comment #15)
> After looking some more at the code, I might have an idea what's causing the
> issue:
> __objc_gnu_init calls __objc_exec_class on _OBJC_MODULES. Is it possible that
> this call is not made for some reason if you link your lib as a dll? That would
> mean the classes are never loaded into the runtime.

I did recently some bugfix for libobjc (shared) for the version in gcc's source
tree. Issue was that the DLL generation was pretty broken in different ways,
which lead then to the issue that no function was exported by it.
This should be fixed on 4.6 version and initial tests are showing it works for
me now.
But in general it is wise to use - if building shared libraries for win32
targets - to use instead of the dllexport/dllimport mechanism the linker option
--export-all-symbols. The issue for obj-c is, that class can't have
dllimport/dllexport attributes, which cause then that their names can't be
found.

I hope it helps,
Kai

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

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues <rwild at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwild at gcc dot gnu.org

--- Comment #17 from Ralf Wildenhues <rwild at gcc dot gnu.org> 2010-11-03 17:11:18 UTC ---
JFTR, libtool will not create a shared library on w32 systems unless you pass
the -no-undefined flag at link time.  That seems to me the reason why libobjc
is created as static only.

Whether you need to make other adjustments for shared libobjc to actually work,
I cannot tell without more details.

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

[js-gcc at webkeks dot org]

------- Comment #15 from js-gcc at webkeks dot org  2009-12-20 00:31 -------
After looking some more at the code, I might have an idea what's causing the
issue:
__objc_gnu_init calls __objc_exec_class on _OBJC_MODULES. Is it possible that
this call is not made for some reason if you link your lib as a dll? That would
mean the classes are never loaded into the runtime.


-- 


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

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

[js-gcc at webkeks dot org]

------- Comment #14 from js-gcc at webkeks dot org  2009-07-16 21:16 -------
Any comments? This is still very annoying and completely killing the ability to
have plugins/bundles on win32.


-- 


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

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

[js-gcc at webkeks dot org]

------- Comment #13 from js-gcc at webkeks dot org  2009-06-09 19:27 -------
Oh, for the record:
cygwin now has gcc4 imported and they have libobjc as a shared .dll file. Using
their dll, it works. So this means libobjc works with dll files if it is a dll
file itself. But unfortunately, it's not possible to build it as a dll for
mingw32 it seems.

Still, I think there should be either both (.dll and .a) or the .a file should
be able to load other dlls. Having only a .dll would mean that every app
depends on libobjc.dll, which most likely no windows user will have. That's as
if every C++ app would require gcc's libstdc++.dll on Windows.


-- 


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

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

[js-gcc at webkeks dot org]

------- Comment #12 from js-gcc at webkeks dot org  2009-06-09 19:17 -------
Any news? I even tried this now, which still produced an .a file:

../gcc-4.3.0-20080502/configure -v --prefix=/usr --libexecdir=/usr/lib \
--program-prefix=mingw32- --target=mingw32 --with-headers=/usr/mingw32/include
--disable-nls --enable-shared --enable-languages=objc
make configure-target-libobjc
make all-target-libobjc
make install-target-libobjc

Note the --enable-shared, which is _DEFINITELY_ being passed to configure
(quoting Makefile in builddir):

maybe-configure-target-libobjc: configure-target-libobjc
configure-target-libobjc: 
        @: $(MAKE); $(unstage)
        @r=`${PWD_COMMAND}`; export r; \
        s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
        echo "Checking multilib configuration for libobjc..."; \
        $(SHELL) $(srcdir)/mkinstalldirs $(TARGET_SUBDIR)/libobjc ; \
        $(CC_FOR_TARGET) --print-multi-lib >
$(TARGET_SUBDIR)/libobjc/multilib.tmp 2> /dev/null ; \
        if test -r $(TARGET_SUBDIR)/libobjc/multilib.out; then \
          if cmp -s $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; then \
            rm -f $(TARGET_SUBDIR)/libobjc/multilib.tmp; \
          else \
            rm -f $(TARGET_SUBDIR)/libobjc/Makefile; \
            mv $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; \
          fi; \
        else \
          mv $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; \
        fi; \
        test ! -f $(TARGET_SUBDIR)/libobjc/Makefile || exit 0; \
        $(SHELL) $(srcdir)/mkinstalldirs $(TARGET_SUBDIR)/libobjc ; \
        $(NORMAL_TARGET_EXPORTS) \
        echo Configuring in $(TARGET_SUBDIR)/libobjc; \
        cd "$(TARGET_SUBDIR)/libobjc" || exit 1; \
        case $(srcdir) in \
          /* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
          *) topdir=`echo $(TARGET_SUBDIR)/libobjc/ | \
                sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
        esac; \
        srcdiroption="--srcdir=$${topdir}/libobjc"; \
        libsrcdir="$$s/libobjc"; \
        rm -f no-such-file || : ; \
        CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
          $(TARGET_CONFIGARGS) --build=${build_alias} --host=${target_alias} \
          --target=${target_alias} $${srcdiroption}  \
          || exit 1

And TARGET_CONFIGARS is:

TARGET_CONFIGARGS = --cache-file=./config.cache --enable-multilib
--with-cross-host=i686-pc-linux-gnu '-v' '--prefix=/usr'
'--libexecdir=/usr/lib' '--with-headers=/usr/mingw32/include' '--disable-nls'
'--enable-shared' '--enable-languages=c,objc'
--program-transform-name='s,^,mingw32-,'
--with-target-subdir="$(TARGET_SUBDIR)"

As you can see, --enable-shared is listed there, so libobjc's configure is
simply ignoring --enable-shared it seems.


-- 


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

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

[ayers at gcc dot gnu dot org]

------- Comment #11 from ayers at gcc dot gnu dot org  2009-04-06 21:59 -------
With 'native' I meant mingw := build=host=target so no... it's not native in
the sense that I was talking about.


-- 


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

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

[js-gcc at webkeks dot org]

------- Comment #10 from js-gcc at webkeks dot org  2009-04-06 21:39 -------
What exactly do you mean by native build? Do you mean if I build a compiler to
run on Linux and not on win32, but which targets win32? If so, yes.


-- 


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

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

[ayers at gcc dot gnu dot org]

------- Comment #9 from ayers at gcc dot gnu dot org  2009-04-06 21:22 -------
I'm sorry, I'm simply not familiar with cygwin/mingw environments and cross
builds.  But I'm surprised that --enable-shared doesn't work.  Is that a native
build?


-- 


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

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

[js-gcc at webkeks dot org]

------- Comment #8 from js-gcc at webkeks dot org  2009-04-06 19:41 -------
Any news on this? Any way how I could compile libobjc as a shared library?
Specifying --enable-shared breaks basically every library that gcc ships and I
haven't found a way to only enable it for libobjc.


-- 


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

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

[js-gcc at webkeks dot org]

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

[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

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

[js-gcc at webkeks dot org]

------- Comment #5 from js-gcc at webkeks dot org  2009-03-16 11:46 -------
It would be hard to link to that discussion as that was IRL on FOSDEM in the
GNUstep Dev Room :).
I reported that bug once on the mingw32 list, but they wouldn't really care
about it. After speaking to Nicola Pero on FOSDEM, I decided that it'd be best
to file a bug for libobjc - and so I did :).

For building mingw32 with gcc 4, you could have a look at these Port files I
wrote:
https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-api
https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-binutils
https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-gcc
https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-runtime


-- 


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

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

[ayers at gcc dot gnu dot org]

------- Comment #4 from ayers at gcc dot gnu dot org  2009-03-16 11:41 -------
Well, consider me a "GNUstep guy" yet I'm definitely not a "GNUstep on MinGW32
guy". (Or anything on MinGW32... which is why this a bit difficult, yet I'm
trying to help maintain libobjc so I'll see what I can do.)

Could you please add a link to that discussion?  It seems that I missed it. 
I've found a few mingw32 discussions searching the archive but nothing recent
wrt static linking.

In the meantime I'm learning how to setup a cross tool chain... please be
patient.


-- 


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

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

[js-gcc at webkeks dot org]

------- Comment #3 from js-gcc at webkeks dot org  2009-03-16 11:24 -------
When the target is mingw32, it seems that libobjc is only built as a static
library. This isn't a bad idea after all, because I guess no win32 user has a
libobjc.so installed somewhere, so you would need to ship that file with every
binary produced from ObjC-sources.

I heard from the GNUstep guys that they had the same problem until they linked
libobjc dynamically. But IMO, this is only a workaround - it should also work
if libobjc is linked statically.


-- 


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

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

[ayers at gcc dot gnu dot org]

------- Comment #2 from ayers at gcc dot gnu dot org  2009-03-16 07:27 -------
So the situation seems to be:
- libobjc is a static library.
- libfoo is a dll statically linked against libobjc.
- test is program which is linked both against libfoo and libobjc.

I'm guessing here since I have no experience mingw and with linking libobjc
statically, but I could imagine that you may have two copies of libobjc in your
executable each with it's own set of runtime structures, which may cause
confusion.

Is there any reason why libobjc isn't dynamically linked if you going to use
DLL's?

Note I'll still need to build a mingw compiler and look into the auto-import
warning and I'm not sure when I'll get around to it, so I haven't assigned the
bug yet in case someone else can easily test it.

Cheers,
David


-- 

ayers at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ayers at gcc dot gnu dot org


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