[2445] in SIPB_Linux_Development
Re: Releasing Linux-Athena 5.2
daemon@ATHENA.MIT.EDU (Aaron M. Ucko)
Tue Feb 2 01:47:37 1999
To: Salvatore Valente <svalente@MIT.EDU>
Cc: linux-dev@MIT.EDU
From: amu@MIT.EDU (Aaron M. Ucko)
Date: 02 Feb 1999 01:47:22 -0500
In-Reply-To: Salvatore Valente's message of "Tue, 2 Feb 1999 01:17:50 -0500"
Salvatore Valente <svalente@MIT.EDU> writes:
> Aaron wrote:
>
> Because Red Hat didn't explicitly link all appropriate libraries
> against libc6, we'll also want to replace /sbin/ldconfig with version
> 1.9.9 and edit /etc/ld.so.conf to indicate directory types...
>
> Is this type of stuff documented somewhere? What do we gain by
> changing the version of ldconfig? Should some of this stuff be
> reported to RedHat?
In the docs that come with the dynamic linker. We gain the ability to
tell ldconfig which directories contain which type of library. (If a
library is built properly, it explicitly depends on the appropriate
libc version and ldd can tell what it wants to load, but not all the
libraries Red Hat ships are built properly.)
> If you hadn't mentioned the ldconfig/ld.so.conf stuff, I'd just build
> the athena-libc5 package as follows:
>
> %files
> /usr/lib/terminfo
> /usr/lib/zoneinfo
> /usr/i486-linux-libc5/lib/libdb.so.2.0.0
> /usr/i486-linux-libc5/lib/libgdbm.so.2.0.0
> /usr/i486-linux-libc5/lib/libjpeg.so.6.0.1
> /usr/i486-linux-libc5/lib/libtiff.so.3.4.28
> /usr/i486-linux-libc5/lib/libz.so.1.0.4
>
> %post
> /sbin/ldconfig
>
> What would go wrong with that approach?
The libjpeg Red Hat ships doesn't explicitly depend on libc:
; ldd /usr/lib/libjpeg.so.6
statically linked
so ldd merely notes that it's an ELF shared library associated with an
unidentified libc version:
; ldconfig -p | fgrep libjpeg.so.6
libjpeg.so.62 (ELF) => /usr/lib/libjpeg.so.62
libjpeg.so.62 (ELF) => /usr/lib/libjpeg.so.62
libjpeg.so.6 (ELF) => /usr/lib/libjpeg.so.6
libjpeg.so.6 (ELF) => /usr/lib/libjpeg.so.6
Even if we install a properly built libjpeg in
/usr/i486-linux-libc5/lib (which would get identified as ELF-libc5
rather than ELF), the dynamic loader will favor the library in
/usr/lib because it doesn't know it won't work. (I've determined this
fact experimentally.)
This failure mode doesn't happen with the X libraries because they're
built properly:
; ldd /usr/X11R6/lib/libX11.so.6
libc.so.6 => /lib/libc.so.6 (0x400a8000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
; ldd /usr/i486-linux-libc5/lib/libX11.so.6
libc.so.5 => not found
; ldconfig -p | fgrep libX11.so.6
libX11.so.6 (DLL) => /usr/i486-linuxaout/lib/libX11.so.6
libX11.so.6 (ELF-libc6) => /usr/X11R6/lib/libX11.so.6
libX11.so.6 (ELF-libc5) => /usr/i486-linux-libc5/lib/libX11.so.6
--
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)
