Re: shared lib problem with atexit

["H . J . Lu" <hjl at lucon dot org>]

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.