public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* RE: Linking with -lc
@ 2003-05-08 13:55 Harris, Jeff
  2003-05-08 18:51 ` H. J. Lu
  0 siblings, 1 reply; 14+ messages in thread
From: Harris, Jeff @ 2003-05-08 13:55 UTC (permalink / raw)
  To: 'H. J. Lu', Harris, Jeff
  Cc: amodra, 'binutils@sources.redhat.com'

I am having difficulties trying to create a test case other than the -lc
linking on ppc.

I do have more information regarding the symbols that were generated which
may shed some more light.  The output of nm on the shared library
(optionally linked against libc) and the exe (linked against the shared
library) show different symbol types for the __muldf3 symbol.  The four
cases I have are old/new binutils and with/without linking to -lc.

New binutils, without -lc:
libcfp.so: 00001ed8 t __muldf3
cfp1: 10001648 T __muldf3

New binutils, with -lc:
libcfp.so: U __muldf3@@GLIBC_2.3.2
cfp1: doesn't link

Old binutils, without -lc
libcfp.so: 00001ed8 t __muldf3
cfp1: 10001648 t __muldf3

Old binutils, with -lc
libcfp.so: U __muldf3@@GLIBC_2.3.2
cfp1: 10001648 t __muldf3

Running ld with the -y flag, it appears that __muldf3 comes either from
libgcc.a or libc.so.6 depending on if -lc is specified (libc.so.6) or not
(libgcc.a).

Hopefully this information will help.  I couldn't see how to create a symbol
with the "t" specification to try and duplicate this issue.  I'm a relative
newbie when it comes to ld scripts and forcing symbol types.

Thanks for your help.

Jeff

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: Linking with -lc
@ 2003-05-07 20:40 Harris, Jeff
  2003-05-07 21:51 ` H. J. Lu
  0 siblings, 1 reply; 14+ messages in thread
From: Harris, Jeff @ 2003-05-07 20:40 UTC (permalink / raw)
  To: 'H. J. Lu', Harris, Jeff
  Cc: amodra, 'binutils@sources.redhat.com'

[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]

The enclosed test works fine.  Looking at the glibc Versions file for the
nofpu powerpc, it looks as if it is ppc specific.  I've included a small
test case which demonstrates the problem.

> CC=/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc make all
/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -fPIC   -c -o
fplib.o fplib.c
/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -shared -o
libcfp.so fplib.o
/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -fPIC   -c -o
fp1.o fp1.c
/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -g fp1.o -o cfp
-L. -lcfp

Compiles just fine.  However:

> CC=/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc make all
SOFLAGS=-lc
/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -fPIC   -c -o
fplib.o fplib.c
/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -shared -o
libcfp.so fplib.o -lc
/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -fPIC   -c -o
fp1.o fp1.c
/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -g fp1.o -o cfp
-L. -lcfp
./libcfp.so: undefined reference to `__muldf3@GLIBC_2.3.2'
collect2: ld returned 1 exit status
make: *** [cfp] Error 1

Fails.  The test also succeeds using a compiler for Linux/x86.

Would it suffice to just add the symbols in the Versions file to the .hidden
section of libgcc-compat.S?


Jeff

-----Original Message-----
From: H. J. Lu [mailto:hjl@lucon.org] 
Sent: Wednesday, May 07, 2003 4:09 PM
To: Harris, Jeff
Cc: amodra@bigpond.net.au; 'binutils@sources.redhat.com'
Subject: Re: Linking with -lc


On Wed, May 07, 2003 at 12:47:17PM -0700, H. J. Lu wrote:
> 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.
> 

The enclosed testcase works fine on Linux/x86. Please try it on your
ppc box. If it doesn't work for you, that means there is a ppc specific
bug. If it does work for you, you need to provide a small testcase to
show how to reproduce it.


H.J.
--
# make
cc -fPIC   -c -o ref.o ref.c
cc -fPIC   -c -o foo.o foo.c
ld -o foo.so -shared --version-script=foo.v foo.o -rpath .
ar rv foo.a foo.o
r - foo.o
ld -o ref.so -shared ref.o foo.so foo.a -rpath .
cc    -c -o main.o main.c
cc -o main main.o ref.so foo.so


[-- Attachment #2: fpbug.tgz --]
[-- Type: application/octet-stream, Size: 558 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: Linking with -lc
@ 2003-05-07 19:39 Harris, Jeff
  2003-05-07 19:47 ` H. J. Lu
  0 siblings, 1 reply; 14+ messages in thread
From: Harris, Jeff @ 2003-05-07 19:39 UTC (permalink / raw)
  To: 'H. J. Lu', Harris, Jeff, amodra
  Cc: 'binutils@sources.redhat.com'

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Linking with -lc
@ 2003-05-07 18:55 Harris, Jeff
  2003-05-07 19:20 ` H. J. Lu
  2003-05-07 19:37 ` Thiemo Seufer
  0 siblings, 2 replies; 14+ messages in thread
From: Harris, Jeff @ 2003-05-07 18:55 UTC (permalink / raw)
  To: 'binutils@sources.redhat.com'

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
The __muldf3 symbol is an undefined global symbol: __muldf3@@GLIBC_2.3.2.

This occurs whether I'm using the old (2.13.90.0.20) or new binutils.  The
different symbol definitions are due to ld finding the __muldf3 symbol in
libgcc.a (the first case) or libc.so.6 (the second case)

My problem comes in linking a program against the libcfp.so library.  If I
have a program which also uses soft floating point operations, the program
fails to link with the libcfp built with -lc:
	/usr/local/ai/ppc8xx-lx2.4-1.00rc4/bin/powerpc-ai-linux-gcc -g fp1.c
-o cfp1 -L. -lcfp
	./libcfp.so: undefined reference to `__muldf3@GLIBC_2.3.2'
	collect2: ld returned 1 exit status

If I remove the -lc flag in the link of libcfp.so, the cfp1 program links
successfully.  This situation also works in both cases using the
2.13.90.0.20 binutils.  I can not use the 2.13 binutils due to a bug with ld
relating to printf statements and -O2 optimizations.  The 2.14 version fixes
the ld crash.

It seems safe enough to remove -lc flag, but it is being added in some third
party packages which we are importing and would prefer not to have to
modify.

Is there anything I can do to fix this situation without modifying the
package?  It seems like a bug in the loader or perhaps a deprecated feature.
I would appreciate any suggestions.

Thanks,
Jeff

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-05-08 19:52 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-08 13:55 Linking with -lc Harris, Jeff
2003-05-08 18:51 ` H. J. Lu
2003-05-08 19:23   ` PATCH: Fix hidden vs. versioned symbol H. J. Lu
2003-05-08 19:52     ` H. J. Lu
  -- strict thread matches above, loose matches on Subject: below --
2003-05-07 20:40 Linking with -lc Harris, Jeff
2003-05-07 21:51 ` H. J. Lu
2003-05-07 19:39 Harris, Jeff
2003-05-07 19:47 ` H. J. Lu
2003-05-07 20:09   ` H. J. Lu
2003-05-08  8:42   ` Franz Sirl
2003-05-08 13:52     ` H. J. Lu
2003-05-07 18:55 Harris, Jeff
2003-05-07 19:20 ` H. J. Lu
2003-05-07 19:37 ` Thiemo Seufer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).