This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: shared lib problem with atexit
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.