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 libgcc.so).
As I compile on a development machine, and deploy on another, I don't want
to bring libgcc.so 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/mod_status.so into server: ld.so.1:
/opt/apache/bin/httpd: fatal: relocation error: file
/opt/apache/modules/mod_status.so: symbol __floatdisf: referenced symbol not
found
This also happen with mod_auth_digest.so...
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... :-)
Pier
