httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <>
Subject Re: Solaris 8 + gcc 3.2.1 + libtool = fuckup...
Date Tue, 07 Jan 2003 08:52:03 GMT
Pier Fumagalli wrote:
> Again, here goes my little problem :-( I'm trying to compile 2.0.43 on a
> Solaris 8.0 (latest patches) machine, using gcc-3.2.1 (which I compiled) and
> the libtool coming in the dist (no, I didn't re-run buildconf), and I have
> one problem.
> Let's start by saying that my "gcc" is compiled with "--enable-static
> --disable-shared" (which is going to make things complicated), so libgcc is
> only available as "libgcc.a" (no
> As I compile on a development machine, and deploy on another, I don't want
> to bring around, so, with everything else, it works...
> Now, the problem is the following: when I compile httpd, and try to invoke
> "httpd -t", it'll simply refuse to load saying:
> Cannot load /opt/apache/modules/ into server:
> /opt/apache/bin/httpd: fatal: relocation error: file
> /opt/apache/modules/ symbol __floatdisf: referenced symbol not
> found
> This also happen with
> Tracing down the problem, it seems that libgcc defines __floatdisf, but the
> ./configure process never figures out that it'll need to link certain
> modules against it.
> The odd thing (odd, well, its ANOTHER libtool bug) is that when I specify
> LDFLAGS="-lgcc" to configure, all modules are created as static libraries
> (because libtool cowardly refuses to link something against a static and a
> shared library)...
> Now, gcc _correctly_ links any executable to the correct library libgcc.a
> automagically (if I call it from the command line), _but_ libtool is stupid,
> and assumes that when we want to link a library, we can simply call "ld"
> automatically without caring about what GCC might have to say...
> And then I get into a deadlock... To compile mod_status and mod_auth_digest,
> I need to use libtool, but libtool calls ld directly without the inclusion
> of libgcc, so, basically, I'm foobared...
> My quick-and-dirty solution was to call LD myself adding libgcc on the
> command line and manually re-link the two modules, but I bet that I'm not
> the only one who will get into this problem as HTTPD-2.0 gets deployed more
> widely (this doesn't happen with 1.3).
> I haven't tried with Justin's jlibtool (as it doesn't want to work against
> the latest 2.0.43, darn) but if someone wants to do what I did, and use
> libgcc static, is going to run into troubles...
> Now, I tried to do two things: link httpd including libgcc and adding
> libgcc.a to libapr... They both don't work, so, at the end, I'll have to
> hack every module depending on something defined by libgcc (apxs won't work
> for those modules)...
> Anyone got a friggin' CLUE? Throw me a bone out here! :-) :-)
> BTW, if someone wants an account on the troublesome set of machines, just
> let me know... :-)

I remember trying gnu ld instead of native ld.

I have just tried to build gcc 3.2.1 (and tell him to use native ld) on my 
machine but it fails:
/export/home2/jfclere/gcc-3.2/libjava/ `__builtin_va_arg_incr'
    undeclared (first use this function)
gmake[5]: *** [prims.lo] Error 1
gmake[5]: Leaving directory `/export/home2/jfclere/gcc/sparc-sun-solaris2.8/spar
Does this sound to someone?

>     Pier

View raw message