This is the mail archive of the
mailing list for the glibc project.
Re: Linking with -lc
- From: "H. J. Lu" <hjl at lucon dot org>
- To: "Harris, Jeff" <JeffH at aiinet dot com>
- Cc: amodra at bigpond dot net dot au,GNU C Library <libc-alpha at sources dot redhat dot com>,"'binutils at sources dot redhat dot com'" <binutils at sources dot redhat dot com>
- Date: Wed, 7 May 2003 12:47:17 -0700
- Subject: Re: Linking with -lc
- References: <3B785392832ED71192AE00D0B7B0D75B1C6498@aimail.aiinet.com>
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
> 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
> -----Original Message-----
> From: H. J. Lu [mailto:firstname.lastname@example.org]
> Sent: Wednesday, May 07, 2003 3:21 PM
> To: Harris, Jeff; email@example.com
> Cc: 'firstname.lastname@example.org'
> 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
> > 220.127.116.11.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.