[Top] [All Lists]

Re: gcc -shared ... -lc ?

Subject: Re: gcc -shared ... -lc ?
Date: Mon, 5 Jan 1998 22:09:16 +0100
In-reply-to: <>; from Thomas Bogendoerfer on Mon, Jan 05, 1998 at 06:45:10PM +0100
References: <>
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 @@
>         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 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:


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

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


<Prev in Thread] Current Thread [Next in Thread>