httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Solaris 8 + gcc 3.2.1 + libtool = fuckup...
Date Sun, 05 Jan 2003 19:00:13 GMT

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 
> it
> _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).

I see what you mean now. This still isn't really a bug in either (more 
a bug
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 the
> 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).

This is probably because that would be a non-portable option. Some 
platforms
(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


Mime
View raw message