This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: Linking with -lc
- From: "Harris, Jeff" <JeffH at aiinet dot com>
- To: "'H. J. Lu'" <hjl at lucon dot org>, "Harris, Jeff" <JeffH at aiinet dot com>, amodra at bigpond dot net dot au
- Cc: "'binutils at sources dot redhat dot com'" <binutils at sources dot redhat dot com>
- Date: Wed, 7 May 2003 15:38:49 -0400
- Subject: RE: Linking with -lc
The output from the objdump command is:
00114fa4 g DF .text 00000894 GLIBC_2.3.2 __muldf3
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.
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.