This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]