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 08:31:26 GMT
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.

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.

This has nothing to do with libtool nor autoconf.

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.

Hope that helps,
-aaron


p.s. To satisfy my curiosity, I compiled the asm and stared at it
for awhile. It looks like the __floatdisf calls are being used to
convert and apr_off_t (a double int) to a float:

static void format_byte_out(request_rec *r, apr_off_t bytes)
{
     if (bytes < (5 * KBYTE))
         ap_rprintf(r, "%d B", (int) bytes);
     else if (bytes < (MBYTE / 2))
         ap_rprintf(r, "%.1f kB", (float) bytes / KBYTE);
     else if (bytes < (GBYTE / 2))
         ap_rprintf(r, "%.1f MB", (float) bytes / MBYTE);
     else
         ap_rprintf(r, "%.1f GB", (float) bytes / GBYTE);
}



On Saturday, January 4, 2003, at 05:29  PM, 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 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


Mime
View raw message