shared lib problem with atexit

shared lib problem with atexit

[Bruno Haible]

Hi, ELF experts,

With recent glibc, I'm getting a link error when trying to build applications
using libqt. I don't understand where the problem lies - in libc or in the
linker.

$ gcc hello.c -lqt
/packages/gnu/XFree86/lib/libX11.so.6: undefined reference to `atexit'
collect2: ld returned 1 exit status

where hello.c is a trivial C hello-world program.

The situation:

- CPU is i686,
- gcc is gcc-2.95.3.
- binutils (as, ld, ...) are binutils-2.10.0.18 and identify themselves as
  "GNU ld 2.10.90".
- /usr/lib/libqt.so.1 and /usr/lib/libqt.so.2 are from SuSE 7.0.
- on 2001-04-12, I installed glibc-2001-03-15 from sources, with
  --prefix=/usr,
- on 2001-04-21, I installed XFree86-4.0.99.2 from sources, with
  --prefix=/packages/gnu/XFree86
- now I installed glibc-2001-04-30 from sources, with --prefix=/usr.

The source:
====================== hello.c ===========================
#include <stdio.h>
main ()
{
  printf("Hello, world.\n");
  return 0;
}
==========================================================

The link error occurs when I have set LD_LIBRARY_PATH.
Without LD_LIBRARY_PATH:
  $ gcc hello.c -lqt
  OK
With LD_LIBRARY_PATH:
  $ LD_LIBRARY_PATH=/packages/gnu/XFree86/lib \
    gcc hello.c -lqt
  /packages/gnu/XFree86/lib/libX11.so.6: undefined reference to `atexit'
  collect2: ld returned 1 exit status

Calling collect2 directly:

  $ LD_LIBRARY_PATH=/packages/gnu/XFree86/lib \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/collect2 -m elf_i386 \
    -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/crtbegin.o \
    -L/packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3 -L/usr/local/lib \
    hello.o -lqt \
    -lgcc -lc -lgcc \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/crtend.o /usr/lib/crtn.o
  /packages/gnu/XFree86/lib/libX11.so.6: undefined reference to `atexit'
  collect2: ld returned 1 exit status

Same with "-lqt" replaced by "/usr/lib/libqt.so.1" or "/usr/lib/libqt.so.2".

libX11 comes in as a dependency from libqt.

  $ ldd /usr/lib/libqt.so.1
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401f7000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x402c7000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x402d5000)
        libc.so.6 => /lib/libc.so.6 (0x402f4000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

  $ LD_LIBRARY_PATH=/packages/gnu/XFree86/lib \
    ldd /usr/lib/libqt.so.1
        libX11.so.6 => /packages/gnu/XFree86/lib/libX11.so.6 (0x401eb000)
        libXext.so.6 => /packages/gnu/XFree86/lib/libXext.so.6 (0x402cb000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x402e5000)
        libc.so.6 => /lib/libc.so.6 (0x40304000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

How do these libraries refer to 'atexit'?

  $ nm /usr/lib/libqt.so.1 | grep atexit
         U atexit@@GLIBC_2.0
  $ nm /usr/lib/libqt.so.2 | grep atexit
         U atexit@@GLIBC_2.0
  $ nm /usr/X11R6/lib/libX11.so.6 | grep atexit
         U atexit@@GLIBC_2.0
  $ nm /packages/gnu/XFree86/lib/libX11.so.6 | grep atexit
         U atexit

So the difference between without/with LD_LIBRARY_PATH is that the libX11
it uses refers to a qualified/unqualified 'atexit' symbol.

Another strange behaviour is that when I explicitly insert the libX11
that causes the error into the link command line, the error goes away!

  $ LD_LIBRARY_PATH=/packages/gnu/XFree86/lib \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/collect2 -m elf_i386 \
    -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/crtbegin.o \
    -L/packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3 -L/usr/local/lib \
    hello.o /usr/lib/libqt.so.1 /packages/gnu/XFree86/lib/libX11.so.6 \
    -lgcc -lc -lgcc \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/crtend.o /usr/lib/crtn.o
  OK!!

Or when /usr/lib/libqt.so.1 is dropped and only libX11.so.6 is referred to,
the error goes away as well.

  $ LD_LIBRARY_PATH=/packages/gnu/XFree86/lib \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/collect2 -m elf_i386 \
    -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/crtbegin.o \
    -L/packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3 -L/usr/local/lib \
    hello.o /packages/gnu/XFree86/lib/libX11.so.6 \
    -lgcc -lc -lgcc \
    /packages/gnu/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/crtend.o /usr/lib/crtn.o
  OK!!

Another strange point is the list of undefined symbols of the two libraries:

$ diff <(nm /usr/X11R6/lib/libX11.so.6 | grep ' U ') \
       <(nm /packages/gnu/XFree86/lib/libX11.so.6 | grep ' U ')
...
15c16
<          U atexit@@GLIBC_2.0
---
>          U atexit
...

$ nm /usr/X11R6/lib/libX11.so.6 | grep ' U '
         U _IO_getc@@GLIBC_2.0
         U _IO_putc@@GLIBC_2.0
         U ___brk_addr@@GLIBC_2.0
         U __ctype_b@@GLIBC_2.0
         U __ctype_get_mb_cur_max@@GLIBC_2.0
         U __ctype_tolower@@GLIBC_2.0
         U __ctype_toupper@@GLIBC_2.0
         U __curbrk@@GLIBC_2.0
         U __environ@@GLIBC_2.0
         U __errno_location@@GLIBC_2.0
         U __fxstat@@GLIBC_2.0
         U __strtol_internal@@GLIBC_2.0
         U __xstat@@GLIBC_2.0
         U access@@GLIBC_2.0
         U atexit@@GLIBC_2.0
         U calloc@@GLIBC_2.0
         U close@@GLIBC_2.0
         U connect@@GLIBC_2.0
         U exit@@GLIBC_2.0
         U fclose@@GLIBC_2.1
         U fcntl@@GLIBC_2.0
         U ferror@@GLIBC_2.0
         U fflush@@GLIBC_2.0
         U fgets@@GLIBC_2.0
         U fileno@@GLIBC_2.0
         U fopen@@GLIBC_2.1
         U fprintf@@GLIBC_2.0
         U fputs@@GLIBC_2.0
         U fread@@GLIBC_2.0
         U free@@GLIBC_2.0
         U fwrite@@GLIBC_2.0
         U getenv@@GLIBC_2.0
         U gethostbyname@@GLIBC_2.0
         U getpeername@@GLIBC_2.0
         U getpid@@GLIBC_2.0
         U getpwnam_r@@GLIBC_2.0
         U getpwuid_r@@GLIBC_2.0
         U getservbyname@@GLIBC_2.0
         U getsockname@@GLIBC_2.0
         U getuid@@GLIBC_2.0
         U inet_addr@@GLIBC_2.0
         U ioctl@@GLIBC_2.0
         U malloc@@GLIBC_2.0
         U mblen@@GLIBC_2.0
         U mbtowc@@GLIBC_2.0
         U memcpy@@GLIBC_2.0
         U memmove@@GLIBC_2.0
         U memset@@GLIBC_2.0
         U open@@GLIBC_2.0
         U pthread_cond_broadcast@@GLIBC_2.0
         U pthread_cond_destroy@@GLIBC_2.0
         U pthread_cond_init@@GLIBC_2.0
         U pthread_cond_signal@@GLIBC_2.0
         U pthread_cond_wait@@GLIBC_2.0
         U pthread_equal@@GLIBC_2.0
         U pthread_mutex_destroy@@GLIBC_2.0
         U pthread_mutex_init@@GLIBC_2.0
         U pthread_mutex_lock@@GLIBC_2.0
         U pthread_mutex_unlock@@GLIBC_2.0
         U pthread_self@@GLIBC_2.0
         U qsort@@GLIBC_2.0
         U read@@GLIBC_2.0
         U readv@@GLIBC_2.0
         U realloc@@GLIBC_2.0
         U rewind@@GLIBC_2.0
         U select@@GLIBC_2.0
         U setlocale@@GLIBC_2.0
         U setsockopt@@GLIBC_2.0
         U shutdown@@GLIBC_2.0
         U sleep@@GLIBC_2.0
         U socket@@GLIBC_2.0
         U sprintf@@GLIBC_2.0
         U sscanf@@GLIBC_2.0
         U stderr@@GLIBC_2.0
         U strcat@@GLIBC_2.0
         U strchr@@GLIBC_2.0
         U strcmp@@GLIBC_2.0
         U strcpy@@GLIBC_2.0
         U strerror@@GLIBC_2.0
         U strncmp@@GLIBC_2.0
         U strncpy@@GLIBC_2.0
         U strrchr@@GLIBC_2.0
         U time@@GLIBC_2.0
         U uname@@GLIBC_2.0
         U ungetc@@GLIBC_2.0
         U unlink@@GLIBC_2.0
         U wctomb@@GLIBC_2.0
         U write@@GLIBC_2.0
         U writev@@GLIBC_2.0
$ nm /packages/gnu/XFree86/lib/libX11.so.6 | grep ' U '
         U _IO_getc@@GLIBC_2.0
         U _IO_putc@@GLIBC_2.0
         U ___brk_addr@@GLIBC_2.0
         U __ctype_b@@GLIBC_2.0
         U __ctype_get_mb_cur_max@@GLIBC_2.0
         U __ctype_tolower@@GLIBC_2.0
         U __ctype_toupper@@GLIBC_2.0
         U __curbrk@@GLIBC_2.0
         U __environ@@GLIBC_2.0
         U __errno_location@@GLIBC_2.0
         U __fxstat@@GLIBC_2.0
         U __strtol_internal@@GLIBC_2.0
         U __xstat@@GLIBC_2.0
         U abort@@GLIBC_2.0
         U access@@GLIBC_2.0
         U atexit
         U calloc@@GLIBC_2.0
         U close@@GLIBC_2.0
         U connect@@GLIBC_2.0
         U exit@@GLIBC_2.0
         U fclose@@GLIBC_2.1
         U fcntl@@GLIBC_2.0
         U ferror@@GLIBC_2.0
         U fflush@@GLIBC_2.0
         U fgets@@GLIBC_2.0
         U fileno@@GLIBC_2.0
         U fopen@@GLIBC_2.1
         U fprintf@@GLIBC_2.0
         U fputs@@GLIBC_2.0
         U fread@@GLIBC_2.0
         U free@@GLIBC_2.0
         U fwrite@@GLIBC_2.0
         U getenv@@GLIBC_2.0
         U gethostbyname@@GLIBC_2.0
         U getpeername@@GLIBC_2.0
         U getpwnam_r@@GLIBC_2.1.2
         U getpwuid_r@@GLIBC_2.1.2
         U getservbyname@@GLIBC_2.0
         U getsockname@@GLIBC_2.0
         U getuid@@GLIBC_2.0
         U inet_addr@@GLIBC_2.0
         U ioctl@@GLIBC_2.0
         U malloc@@GLIBC_2.0
         U mblen@@GLIBC_2.0
         U mbtowc@@GLIBC_2.0
         U memcpy@@GLIBC_2.0
         U memmove@@GLIBC_2.0
         U memset@@GLIBC_2.0
         U open@@GLIBC_2.0
         U pthread_cond_broadcast@@GLIBC_2.0
         U pthread_cond_destroy@@GLIBC_2.0
         U pthread_cond_init@@GLIBC_2.0
         U pthread_cond_signal@@GLIBC_2.0
         U pthread_cond_wait@@GLIBC_2.0
         U pthread_equal@@GLIBC_2.0
         U pthread_mutex_destroy@@GLIBC_2.0
         U pthread_mutex_init@@GLIBC_2.0
         U pthread_mutex_lock@@GLIBC_2.0
         U pthread_mutex_unlock@@GLIBC_2.0
         U pthread_self@@GLIBC_2.0
         U qsort@@GLIBC_2.0
         U read@@GLIBC_2.0
         U readv@@GLIBC_2.0
         U realloc@@GLIBC_2.0
         U rewind@@GLIBC_2.0
         U select@@GLIBC_2.0
         U setlocale@@GLIBC_2.0
         U setsockopt@@GLIBC_2.0
         U shmat@@GLIBC_2.0
         U shmctl@@GLIBC_2.2
         U shmdt@@GLIBC_2.0
         U shutdown@@GLIBC_2.0
         U sleep@@GLIBC_2.0
         U socket@@GLIBC_2.0
         U sprintf@@GLIBC_2.0
         U sscanf@@GLIBC_2.0
         U stderr@@GLIBC_2.0
         U strcat@@GLIBC_2.0
         U strchr@@GLIBC_2.0
         U strcmp@@GLIBC_2.0
         U strcpy@@GLIBC_2.0
         U strerror@@GLIBC_2.0
         U strncmp@@GLIBC_2.0
         U strncpy@@GLIBC_2.0
         U strpbrk@@GLIBC_2.0
         U strrchr@@GLIBC_2.0
         U strstr@@GLIBC_2.0
         U uname@@GLIBC_2.0
         U ungetc@@GLIBC_2.0
         U unlink@@GLIBC_2.0
         U wctomb@@GLIBC_2.0
         U write@@GLIBC_2.0
         U writev@@GLIBC_2.0

Why does _only_ 'atexit' refer to a symbol without version?

Bruno

Re: shared lib problem with atexit

[Ulrich Drepper]

Bruno Haible <haible@ilog.fr> writes:

> With recent glibc, I'm getting a link error when trying to build applications
> using libqt. I don't understand where the problem lies - in libc or in the
> linker.

Kick the qt people.  They most definitely have built the DSO without
linking with libc.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: shared lib problem with atexit

[H . J . Lu]

On Tue, May 08, 2001 at 08:31:46AM -0700, Ulrich Drepper wrote:
> Bruno Haible <haible@ilog.fr> writes:
> 
> > With recent glibc, I'm getting a link error when trying to build applications
> > using libqt. I don't understand where the problem lies - in libc or in the
> > linker.
> 
> Kick the qt people.  They most definitely have built the DSO without
> linking with libc.

That is probably true. However, it does break DSOs compiled against
glibc 2.0.x. I am thinking if we should add a libc-compat.a or
something like that. We can build it with

# $(CC) -nostdlib -nostartfiles -r  libc-compat.a atexit.oS

If people have to use those DSOs, they can add -lc_compat.


H.J.

Re: shared lib problem with atexit

[Ulrich Drepper]

"H . J . Lu" <hjl@lucon.org> writes:

> That is probably true. However, it does break DSOs compiled against
> glibc 2.0.x.

This binary is definitely not linked against glibc 2.0.  I don't care
about non-existing problems.  There is so far no reported problem with
glibc 2.0 binaries so why care?

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: shared lib problem with atexit

[H . J . Lu]

On Tue, May 08, 2001 at 08:54:40AM -0700, Ulrich Drepper wrote:
> "H . J . Lu" <hjl@lucon.org> writes:
> 
> > That is probably true. However, it does break DSOs compiled against
> > glibc 2.0.x.
> 
> This binary is definitely not linked against glibc 2.0.  I don't care
> about non-existing problems.  There is so far no reported problem with
> glibc 2.0 binaries so why care?
> 

How long has glibc 2.2.3 been released? I doubt it has been in the
wide use. Why can't we provide a solution for a possible problem
instead of letting people say glibc 2.2.3 breaks their DSOs compiled
against glibc 2.0? We know there is a problem and we can find a
workaround. It is a shame not to prepare for it even if it may not
be necessary.

BTW, the threaded RPC change in glibc 2.2.3 breaks some non-threaded
RPC applications. I have provided a patch for it.


H.J.

Re: shared lib problem with atexit

[Ulrich Drepper]

"H . J . Lu" <hjl@lucon.org> writes:

> We know there is a problem and we can find a workaround. It is a
> shame not to prepare for it even if it may not be necessary.

No, we don't know there is a problem.

> BTW, the threaded RPC change in glibc 2.2.3 breaks some non-threaded
> RPC applications. I have provided a patch for it.

And I have work to do.  My daily job is *not* to work on glibc.  I
have a real job and it requires a lot of attention if I've been away
for some days.  I'll get to it in time.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: shared lib problem with atexit

[Bruno Haible]

Ulrich Drepper writes:

> Kick the qt people.  They most definitely have built the DSO without
> linking with libc.

Why should they build their libqt with "-lc"? It is necessary to give
all the dependencies on the link command line on AIX. But in ELF this
has not been necessary since 1995.

Before jumping to the conclusion, could you (Ulrich or H.J.) please
explain the cause of the error?

- If the problem were in libqt, why does the linker complain about
  libX11? Is the linker's error message buggy?

- What is so special about 'atexit' that the new libX11 refers to 'atexit'
  not 'atexit@@GLIBC_2.0'?

- Why does the linker complain only if this particular libX11 is a libqt
  dependency, but not when I mention this same libX11 on the linker
  command line (with or without libqt)?

Bruno

Re: shared lib problem with atexit

[Ulrich Drepper]

Bruno Haible <haible@ilog.fr> writes:

> Why should they build their libqt with "-lc"? It is necessary to give
> all the dependencies on the link command line on AIX. But in ELF this
> has not been necessary since 1995.

It always is necessary to define the inter-dependencies.  Nobody must
create DSOs other than with gcc -shared which automatically links in
libc.

> Before jumping to the conclusion, could you (Ulrich or H.J.) please
> explain the cause of the error?

Very simple: there is no default symbol atexit anymore.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: shared lib problem with atexit

[H . J . Lu]

On Tue, May 08, 2001 at 07:24:40PM +0200, Bruno Haible wrote:
> Ulrich Drepper writes:
> 
> > Kick the qt people.  They most definitely have built the DSO without
> > linking with libc.
> 
> Why should they build their libqt with "-lc"? It is necessary to give
> all the dependencies on the link command line on AIX. But in ELF this
> has not been necessary since 1995.

"-lc" is needed for symbol versioning.

> 
> Before jumping to the conclusion, could you (Ulrich or H.J.) please
> explain the cause of the error?
> 
> - If the problem were in libqt, why does the linker complain about
>   libX11? Is the linker's error message buggy?

The unversioned atexit is in atexit.oS from /usr/lib/libc_nonshared.a.
If you have an unversioned reference to atexit in some files at the
command line during the final link, atexit will be pulled in from 
/usr/lib/libc_nonshared.a. That is how my proposed workaround works.

> 
> - What is so special about 'atexit' that the new libX11 refers to 'atexit'
>   not 'atexit@@GLIBC_2.0'?

"atexit" in glibc 2.2.3 is hidden from ld. But the dynamic linker will
resolve references to "atexit@@GLIBC_2.0" with "atexit@GLIBC_2.0"

> 
> - Why does the linker complain only if this particular libX11 is a libqt
>   dependency, but not when I mention this same libX11 on the linker
>   command line (with or without libqt)?

If you don't specify libX11, it will be pulled in via DT_NEEDED from
libqt. In that case, the linker won't go back to /usr/lib/libc.so for
any unresolved symbols. The idead is you may have a binrary compitable
libqt which doesn't need libX11.


H.J.

Re: shared lib problem with atexit

[Geoff Keating]

> From: Bruno Haible <haible@ilog.fr>
> Date: Tue, 8 May 2001 19:24:40 +0200 (CEST)
> 
> Ulrich Drepper writes:
> 
> > Kick the qt people.  They most definitely have built the DSO without
> > linking with libc.
> 
> Why should they build their libqt with "-lc"? It is necessary to give
> all the dependencies on the link command line on AIX. But in ELF this
> has not been necessary since 1995.

It has been necessary since symbol versioning was introduced, that is
at least since May 1999.  Libraries need to have all their
dependencies listed on the link line.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: shared lib problem with atexit

[Ben Collins]

On Tue, May 08, 2001 at 07:24:40PM +0200, Bruno Haible wrote:
> Ulrich Drepper writes:
> 
> > Kick the qt people.  They most definitely have built the DSO without
> > linking with libc.
> 
> Why should they build their libqt with "-lc"? It is necessary to give
> all the dependencies on the link command line on AIX. But in ELF this
> has not been necessary since 1995.

They don't have to. However, they use "ld" to link the objects instead
of gcc. With ld, -lc is not implicit, as it is with gcc as the linker.

That is their mistake.

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Re: shared lib problem with atexit

[Bruno Haible]

Thanks, H.J. and Ulrich for explaining.

Ulrich Drepper wrote:
> Kick the qt people.  They most definitely have built the DSO without
> linking with libc.

Actually, "objdump -p" shows that all involved libraries depend on libc.so.6.
So this cannot be the cause. libqt is created via "g++ -shared", and
libX11 via "gcc -shared".

Here is a testcase. On a glibc-2.1.x system, in /root, create the following
source files.

================= low.c =================
void low ()
{
}
================= high.c =================
#include <stdlib.h>

extern void low ();

void high_nop ()
{
}
void high ()
{
  atexit (high_nop);
  low ();
}
================= main.c =================
extern void high ();
int main ()
{
  high ();
  return 0;
}
==========================================

Then, on the glibc-2.1.x system:

# cd /root

# gcc -shared -O -Wall low.c -o liblow.so

# gcc -shared -O -Wall -L/root -llow -Wl,-rpath,/root high.c -o libhigh.so

# LD_LIBRARY_PATH=/root gcc -L/root -lhigh main.c -o main

# LD_LIBRARY_PATH=/root ./main && echo ok
ok

# nm liblow.so | grep atexit
         U atexit@@GLIBC_2.0

# objdump -p liblow.so | grep NEEDED
  NEEDED      libc.so.6

# objdump -p libhigh.so | grep NEEDED
  NEEDED      liblow.so
  NEEDED      libc.so.6

Copy the files to a glibc-2.2.3 system under /root.

# ./main
./main: error while loading shared libraries: cannot open shared object file: cannot load shared object file: No such file or directory

Note the error message is wrong. It should read
./main: error while loading shared libraries: libhigh.so: No such file or directory

# LD_LIBRARY_PATH=/root ./main && echo ok
ok

# gcc -shared -O -Wall low.c -o liblow.so

# LD_LIBRARY_PATH=/root ./main && echo ok
ok

# LD_LIBRARY_PATH=/root gcc -L/root -lhigh main.c -o main
/root/liblow.so: undefined reference to `atexit'
collect2: ld returned 1 exit status

# nm liblow.so | grep atexit
         U atexit

# objdump -p liblow.so | grep NEEDED
  NEEDED      libc.so.6

# objdump -p libhigh.so | grep NEEDED
  NEEDED      liblow.so
  NEEDED      libc.so.6

It looks like an ld bug to me. If the runtime linker can resolve 'atexit'
from liblow.so to 'atexit@GLIBC_2.0' in libc.so.6, why doesn't ld do the
same when 'main' is linked?

This occurs with both ld-2.9.5.0.24 and ld-2.10.0.18.

Note: This is not a _compatibility_ bug; you can reproduce the error by
doing the following on the glibc-2.2.3 system, without resorting to a
glibc-2.1.x system:

# cd /root
# gcc -shared -O -Wall low.c -o liblow.so
# gcc -shared -O -Wall -L/root -llow -Wl,-rpath,/root high.c -o libhigh.so
# LD_LIBRARY_PATH=/root gcc -L/root -lhigh main.c -o main
/root/liblow.so: undefined reference to `atexit'
collect2: ld returned 1 exit status

Bruno

Re: shared lib problem with atexit

[Jakub Jelinek]

On Wed, May 09, 2001 at 02:50:13PM +0200, Bruno Haible wrote:
> Copy the files to a glibc-2.2.3 system under /root.
...
> # gcc -shared -O -Wall low.c -o liblow.so
    ^^^ what gcc is this?

If it is not gcc 2.95.4 CVS, gcc-2.96-RH of recent vintage, gcc-3_0-branch
of recent vintage or recent gcc CVS head, then it will not work as you
describe on ia32. The issue is that those gcc's referenced atexit (as
workaround for some libc 5 bugs I think) in crtendS.o (and as this is
always after -lc, atexit.oS from libc_nonshared.a simply was not brought
in).
I'd say it is a user bug not to use one of the above compilers with
glibc 2.2.3.

	Jakub

Re: shared lib problem with atexit

[Bruno Haible]

Jakub Jelinek writes:
> > # gcc -shared -O -Wall low.c -o liblow.so
>     ^^^ what gcc is this?

It's a gcc-2.95.3. The latest release approved by the GCC steering
committee.

> The issue is that those gcc's referenced atexit (as workaround for
> some libc 5 bugs I think) in crtendS.o (and as this is always after
> -lc, atexit.oS from libc_nonshared.a simply was not brought in).

Yes, I noticed that too. But if the dynamic linker can cope with the
situation that 'liblow.so' wants 'atexit' and libc.so.6 offers only
'atexit@GLIBC_2.0', then why does ld not do the same?

> If it is not gcc 2.95.4 CVS, gcc-2.96-RH of recent vintage, gcc-3_0-branch
> of recent vintage or recent gcc CVS head, then it will not work as you
> describe on ia32. 
> I'd say it is a user bug not to use one of the above compilers with
> glibc 2.2.3.

Oh well, I hadn't read the glibc-2.2.3 announcement carefully enough :-(

Bruno

Re: shared lib problem with atexit

[Ulrich Drepper]

Bruno Haible <haible@ilog.fr> writes:

> Yes, I noticed that too. But if the dynamic linker can cope with the
> situation that 'liblow.so' wants 'atexit' and libc.so.6 offers only
> 'atexit@GLIBC_2.0', then why does ld not do the same?

The dynamic linker doesn't do anything.  There is no default version
for atexit and therefore it fails.  Just like ld.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------