RE: Linking with -lc

RE: Linking with -lc

[Harris, Jeff]

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.

Re: Linking with -lc

[H. J. Lu]

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.

Re: Linking with -lc

[H. J. Lu]

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

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: bug.tar.gz --]
[-- Type: application/x-gzip, Size: 500 bytes --]

Re: Linking with -lc

[Franz Sirl]

At 21:47 07.05.2003, 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.

Argh, this somehow passed me by. This means glibc-2.3.2 is quite broken in 
the ppc-nofpu case. If these symbols are exported at all from glibc, they 
shouldn't be exported as default symbols. So at least a libgcc-compat.S is 
needed here (a Version script extension to create a non-default versioned 
symbol would be nice), even better would be to remove the symbols from the 
Versions file again, I don't think there are glibc-2.3.2 based nofpu 
distros out there, so that should be fine. What was the reasoning to add 
these symbols in the first place?

> > 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.

That's normal behaviour, libgcc has all these symbols and gcc correctly 
links '-lgcc -lc -lgcc', but adding -lc to the gcc link line undos that and 
then breaks with a the broken glibc-2.3.2.

Franz.

Re: Linking with -lc

[H. J. Lu]

On Thu, May 08, 2003 at 10:42:35AM +0200, Franz Sirl wrote:
> 
> That's normal behaviour, libgcc has all these symbols and gcc correctly 
> links '-lgcc -lc -lgcc', but adding -lc to the gcc link line undos that and 
> then breaks with a the broken glibc-2.3.2.
> 

The thing is even if glibc is broken, ld should still work. But I
can't find a testcase to show the bug under x86.

H.J.

Re: Linking with -lc

[H. J. Lu]

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

On Thu, May 08, 2003 at 09:55:12AM -0400, Harris, Jeff wrote:
> 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.
> 

I found a testcase:

# make
cc -fPIC   -c -o main.o main.c
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 .
cc    -c -o hidden.o hidden.c
ar rv hidden.a hidden.o
a - hidden.o
ld -o ref.so -shared ref.o foo.so hidden.a -rpath .
cc -o main main.o ref.so hidden.a foo.so
ref.so: undefined reference to `foo@VERS.0'
collect2: ld returned 1 exit status
make: *** [main] Error 1

I will fix that.


H.J.

[-- Attachment #2: bug.tar.gz --]
[-- Type: application/x-gzip, Size: 576 bytes --]

RE: Linking with -lc

[Harris, Jeff]

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

Re: Linking with -lc

[H. J. Lu]

On Wed, May 07, 2003 at 04:40:19PM -0400, Harris, Jeff wrote:
> 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.
> 

You are testing different libc/libgcc on ppc and x86. Please try to
come up with a testcase which doesn't involve libc nor libgcc.


H.J.

RE: Linking with -lc

[Harris, Jeff]

[-- 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 --]

Re: Linking with -lc

[Thiemo Seufer]

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.
[snip]
> 	/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
[snip]
> 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.

The problem is old glibc imported some symbols accidentially from libgcc
and stopped to do so.

http://sources.redhat.com/ml/libc-alpha/2002-08/msg00189.html
is probably a good starting point.


Thiemo

Re: Linking with -lc

[H. J. Lu]

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.

Linking with -lc

[Harris, Jeff]

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