On Sunday, January 5, 2003, at 07:25 AM, Pier Fumagalli wrote:
Well, no, it's not a GCC bug, as if you link any executable using GCC itI see what you mean now. This still isn't really a bug in either (more a bug
_will_ work... The problem is that "libtool" doesn't use GCC for linking
libraries, but rather relies on the native Solaris LD, which (of course),
doesn't know about libgcc.a...
If instead libtool used GCC for linking, then GCC would invoke the same LD
but automagically specifying the libgcc.a thing on the command line (if you
do it manually and use verbose compilation, you'll see that it is actually
passed as a parameter to LD).
when you put the two together). GCC is adding an implicit dependency that
libtool can't know about. I don't know why it doesn't work, but we should
be nice to be able to specify LD=gcc when we run configure.
I tried this, _but_ it won't work... If you specify the library in theThis is probably because that would be a non-portable option. Some platforms
LDFLAGS, libtool will refuse to create shared libraries if one of the
objects is an AR archive (as libgcc.a)...
It will build the modules, but all of them will simply be AR archives (and
that ain't good).
(like AIX) can't link dynamic modules against static libraries.
You could make an ld wrapper script and put it early in your PATH:
#!/bin/sh
test x$* != x && exec /usr/ccs/bin/ld $* `gcc -print-libgcc-file-name`
exec /usr/ccs/bin/ld
(just brainstorming, I haven't actually tried this)
-aaron
