httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Solaris 8 + gcc 3.2.1 + libtool = fuckup...
Date Sun, 05 Jan 2003 15:25:36 GMT
On 5/1/03 8:31, "Aaron Bannert" <> wrote:

> Ah yes, I know this problem.
> The problem is simply that you are using gcc with solaris' built in ld
> while ld doesn't implicitly link against libgcc.a. I consider this to
> be a gcc bug.

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

> You already figured out the first workaround, which is to stick libgcc.a
> in your ld parameters. To make this slightly more maintainable you can
> stick this at the end of your ld params: `gcc -print-libgcc-file-name`
> I don't know if this would work, but you might be able to put that
> in your LDFLAGS when running 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 has nothing to do with libtool nor autoconf.

It _has_ to do with libtool, because if I compile the module using GCC
straight, without passing through libtool, the module will compile fine and
will work as well...

> I have some more lengthy replies about this problem in the bugzilla
> database. I'm sure you could search for __floatdisf in there and
> find my postings.

I will... Thanks for helping Aaron...


View raw message