Re: Linking with -lc

["H. J. Lu" <hjl at lucon dot org>]

On Wed, May 07, 2003 at 03:38:49PM -0400, Harris, Jeff wrote:
> The output from the objdump command is:
> 
> 00114fa4 g    DF .text  00000894  GLIBC_2.3.2 __muldf3

This definitely is wrong. __muldf3 in glibc should be for backward
compatibility only. Someone working on pcc should take a look at
sysdeps/powerpc/nofpu/Versions and fix them similar to the way in
sysdeps/powerpc/powerpc32/libgcc-compat.S.

> 
> I didn't mention in my original email, but linking with -lgcc before -lc
> works.  This is what happens when gcc calls ld from the output of gcc -v.
> 

I will see if I can reproduce it on Linux/x86. I suspect it is a ppc
specific bug.


H.J.
> Jeff
> 
> -----Original Message-----
> From: H. J. Lu [mailto:hjl@lucon.org] 
> Sent: Wednesday, May 07, 2003 3:21 PM
> To: Harris, Jeff; amodra@bigpond.net.au
> Cc: 'binutils@sources.redhat.com'
> Subject: Re: Linking with -lc
> 
> 
> On Wed, May 07, 2003 at 02:54:55PM -0400, Harris, Jeff wrote:
> > I am experiencing a strange linking problem since upgrading my binutils to
> > 2.14.90.0.1.  I have a GCC version 3.2.3 cross-compiler for powerpc with
> > soft floating point.  I am using GLIBC 2.3.2.
> > 
> > I have a shared library which uses floating point operations.  I build it
> > as:
> > 	powerpc-ai-linux-gcc -g fplib.c -shared -o libcfp.so
> > As a result, it defines __muldf3 as a local text symbol in libcfp.so.
> > 
> > If, however, I build it as:
> > 	powerpc-ai-linux-gcc -g fplib.c -shared -o libcfp.so -lc
> 
> -lc shouldn't be needed.
> 
> > The __muldf3 symbol is an undefined global symbol: __muldf3@@GLIBC_2.3.2.
> 
> There are 2 problems:
> 
> 1. Glibc 2.3.2 shouldn't export __muldf3 for ld. You need to find out
> why it does. Please provide
> 
> # objdump --dynamic-sym libc.so.6 | grep __muldf3
> 
> 2. Even if glibc is wrong, ld should still work.
> 
> I will see if I can come with a small testcase for Linux/x86.
> 
> 
> H.J.