gcc -shared ... -lc ?

gcc -shared ... -lc ?

[Thomas Bogendoerfer]

Hi,

while compiling redhat 5.0 rpms, I've found something very strange, when
building shared libraries. Some of the built shared libs are very big and
a nm on them shows, that the whole libc (I guess so) is included.  Binaries
inked against these library just dump core. The built line for these shared 
libs always ends with a -lc. Now I'm wondering wether this is a ld bug or
just a user error. What's really weird is the following patch from one
of the redhat rpms:

--- termcap-2.0.8/Makefile.ewt  Tue Jul  8 11:08:00 1997
+++ termcap-2.0.8/Makefile      Tue Jul  8 11:08:12 1997
@@ -41,7 +41,7 @@
 
 $(SHARED_LIB): $(OBJS)
        cd pic; \
-       $(CC) -shared -o ../$@ -Wl,-soname,$(SONAME_SHARED_LIB) $(OBJS)
+       $(CC) -shared -o ../$@ -Wl,-soname,$(SONAME_SHARED_LIB) $(OBJS) -lc
 
 pic:
        -if [ ! -d pic ]; then mkdir pic; fi

So it looks like the ld for alpha and i386 don't include the whole libc
when linked with the comand line above. Any hints ?

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: gcc -shared ... -lc ?

[Timothy Stonis]

 This is a bug in binutils. I think it is fixed in version 2.8.1. Ralf is
more familiar with the problem.

_Tim

On Mon, 5 Jan 1998, Thomas Bogendoerfer wrote:

> Hi,
> 
> while compiling redhat 5.0 rpms, I've found something very strange, when
> building shared libraries. Some of the built shared libs are very big and
> a nm on them shows, that the whole libc (I guess so) is included.  Binaries
> inked against these library just dump core. The built line for these shared 
> libs always ends with a -lc. Now I'm wondering wether this is a ld bug or
> just a user error. What's really weird is the following patch from one
> of the redhat rpms:
> 
> --- termcap-2.0.8/Makefile.ewt  Tue Jul  8 11:08:00 1997
> +++ termcap-2.0.8/Makefile      Tue Jul  8 11:08:12 1997
> @@ -41,7 +41,7 @@
>  
>  $(SHARED_LIB): $(OBJS)
>         cd pic; \
> -       $(CC) -shared -o ../$@ -Wl,-soname,$(SONAME_SHARED_LIB) $(OBJS)
> +       $(CC) -shared -o ../$@ -Wl,-soname,$(SONAME_SHARED_LIB) $(OBJS) -lc
>  
>  pic:
>         -if [ ! -d pic ]; then mkdir pic; fi
> 
> So it looks like the ld for alpha and i386 don't include the whole libc
> when linked with the comand line above. Any hints ?
> 
> Thomas.
> 
> -- 
> See, you not only have to be a good coder to create a system like Linux,
> you have to be a sneaky bastard too ;-)
>                    [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]
> 

Re: gcc -shared ... -lc ?

[ralf]

On Mon, Jan 05, 1998 at 06:45:10PM +0100, Thomas Bogendoerfer wrote:

> while compiling redhat 5.0 rpms, I've found something very strange, when
> building shared libraries. Some of the built shared libs are very big and
> a nm on them shows, that the whole libc (I guess so) is included.  Binaries
> inked against these library just dump core. The built line for these shared 
> libs always ends with a -lc. Now I'm wondering wether this is a ld bug or
> just a user error. What's really weird is the following patch from one
> of the redhat rpms:
> 
> --- termcap-2.0.8/Makefile.ewt  Tue Jul  8 11:08:00 1997
> +++ termcap-2.0.8/Makefile      Tue Jul  8 11:08:12 1997
> @@ -41,7 +41,7 @@
>  
>  $(SHARED_LIB): $(OBJS)
>         cd pic; \
> -       $(CC) -shared -o ../$@ -Wl,-soname,$(SONAME_SHARED_LIB) $(OBJS)
> +       $(CC) -shared -o ../$@ -Wl,-soname,$(SONAME_SHARED_LIB) $(OBJS) -lc
>  
>  pic:
>         -if [ ! -d pic ]; then mkdir pic; fi

The code of libtermcap.so contains dependencies of the libc version it
was compiled with, that's why it has to be linked against libc.  Most
old libraries were not linked against libc.  This became a problem
when with the introduction of libc6 the case of having multiple
libc linked into a program had to be handled.  For example:

  vi
  |--> libtermcap.so.2
       |--> libc.so.6
  |--> libc.so.5

The of course only work right when libtermcap has been linked against
libc.

> So it looks like the ld for alpha and i386 don't include the whole libc
> when linked with the comand line above. Any hints ?

This is a binutils 2.7 bug.  Upgrading to 2.8.1 solves the problem.

  Ralf

Re: gcc -shared ... -lc ?

[Thomas Bogendoerfer]

> > So it looks like the ld for alpha and i386 don't include the whole libc
> > when linked with the comand line above. Any hints ?
> 
> This is a binutils 2.7 bug.  Upgrading to 2.8.1 solves the problem.

this is with binutils-2.8.1

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: gcc -shared ... -lc ?

[Alan Cox]

> > This is a binutils 2.7 bug.  Upgrading to 2.8.1 solves the problem.
> 
> this is with binutils-2.8.1

Oh good its not me seeing things. Ralf - could there be two sets of your
binutils-2.8.1 one working one not and could you maybe post MD5 hashes
of your binaries you know work ?

Re: gcc -shared ... -lc ?

[Alan Cox]

> > This is a binutils 2.7 bug.  Upgrading to 2.8.1 solves the problem.
> 
> this is with binutils-2.8.1

Oh good its not me seeing things. Ralf - could there be two sets of your
binutils-2.8.1 one working one not and could you maybe post MD5 hashes
of your binaries you know work ?

Re: gcc -shared ... -lc ?

[ralf]

On Tue, Jan 06, 1998 at 12:08:38AM +0000, Alan Cox wrote:

> > > This is a binutils 2.7 bug.  Upgrading to 2.8.1 solves the problem.
> > 
> > this is with binutils-2.8.1
> 
> Oh good its not me seeing things. Ralf - could there be two sets of your
> binutils-2.8.1 one working one not and could you maybe post MD5 hashes
> of your binaries you know work ?

Right now I suspect a packaging problem because for me everything is working
fine.  Maybe one of you could verify that it's actually the ld from binutils
2.8.1 that is installed on your systems rsp. contained in the packages you've
used to install?  Check the output of ``ld -v''.

I'll post the MD5 sums later when I return home.

  Ralf

Re: gcc -shared ... -lc ?

[Thomas Bogendoerfer]

On Tue, Jan 06, 1998 at 12:08:38AM +0000, Alan Cox wrote:
> > > This is a binutils 2.7 bug.  Upgrading to 2.8.1 solves the problem.
> > 
> > this is with binutils-2.8.1
> 
> Oh good its not me seeing things. Ralf - could there be two sets of your
> binutils-2.8.1 one working one not and could you maybe post MD5 hashes
> of your binaries you know work ?

I'm using the little endian rpm from ftp.linux.sgi.com. Here is the md5sum:

bce052ce002cbe434133cecf2c4a4f10  binutils-2.8.1-1.mips.rpm

and:

Linux mips.franken.de 2.1.72 #140 Sat Jan 3 23:43:04 MET 1998 mips
[root@mips /root]# ld --version
GNU ld 2.8.1
Copyright 1997 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
  Supported emulations:
   elf32lmip
   elf32bmip
   mipslit
   mipsbig


I'm sure the binutils 2.7, I've used before, didn't have the bug. But
I wanted to make the redhat-5.0 rpms with the newer binutils.

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: gcc -shared ... -lc ?

[Thomas Bogendoerfer]

On Tue, Jan 06, 1998 at 12:16:19AM +0100, Thomas Bogendoerfer wrote:
> > > So it looks like the ld for alpha and i386 don't include the whole libc
> > > when linked with the comand line above. Any hints ?
> > 
> > This is a binutils 2.7 bug.  Upgrading to 2.8.1 solves the problem.
> 
> this is with binutils-2.8.1

Ok, I've found the problem. The installed binutils are 2.8.1, but the
binutils gcc used were 2.7. They got used by gcc, because they were in
/usr/mipsel-linux/bin. I've removed them and all works fine now.

Sorry for the false alarm.

Thomas.


-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]