httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <madhusudan_mathiha...@hp.com>
Subject RE: Solaris 8 + gcc 3.2.1 + libtool = fuckup...
Date Mon, 06 Jan 2003 21:04:35 GMT
ah ha.. I've seen this on HP-UX also.. The problem (as Aaron/Pier mentioned)
is because the LD is not "gcc aware", and is not (cannot be) intelligent
enuf to link libgcc.a automatically. I was thinking it's a HP-UX specific
problem - looks like it's common to other platforms also :-).

Here's what I do : In libtool, set 'deplibs_check_method="pass_all"', and
then pass the archive libraries on the link line. They'll be linked into the
shared library !!.

-Madhu

>-----Original Message-----
>From: Aaron Bannert [mailto:aaron@clove.org]
>Sent: Sunday, January 05, 2003 11:00 AM
>To: dev@httpd.apache.org
>Subject: Re: Solaris 8 + gcc 3.2.1 + libtool = fuckup...
>
>
>
>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