Bug#630411: libc6 should define /lib/ld-lsb-x86-64.so.3 on AMD64
Aurelien Jarno <aurelien@aurel32.net> a écrit
le 13/06/2011 à 23:13:45 :
> > >
> > > LSB compliance is provided through the lsb-core package.
Installing this
> > > package will create, among other things, the /lib64/ld-lsb-x86-64.so.3
> > > symlink.
> >
> > The problem lies in the "among other things" :
> > fp2x@drhpcm03:/etc$ sudo aptitude install lsb-core
> > Les NOUVEAUX paquets suivants vont être installés :
> > alien{a} autopoint{a} cups-bsd{a} cups-client{a} cups-common{a}
> > debhelper{a} ed{a} gettext{a} git{a} html2text{a} intltool-debian{a}
> > lib32z1{a} libcurl3-gnutls{a} libelf1{a} liberror-perl{a}
> > libfile-copy-recursive-perl{a} liblua5.1-0{a} libmail-sendmail-perl{a}
> > librpm1{a} librpmbuild1{a} librpmio1{a} libsys-hostname-long-perl{a}
> > libunistring0{a} lsb-core pax{a} po-debconf{a} rpm{a}
rpm-common{a}
> > rpm2cpio{a} update-inetd{a}
> > 0 paquets mis à jour, 30 nouvellement installés, 0 à enlever
et 0 non mis
> > à jour.
> > Il est nécessaire de télécharger 16,5 Mo d'archives. Après dépaquetage,
> > 37,8 Mo seront utilisés.
> > Voulez-vous continuer ? [Y/n/?] n
> > Abandon.
> >
> > I have 7 debian servers with a minimum set of packages for computations
:
> > openmpi, paraview, ...
> > If possible, I want to avoi unneeded packages, and 30 packages
to get a
> > symlink is a bit heavy.
>
> All these packages are needed for LSB compliance, either you want
LSB
> compliance or not.
Very true. Once upon a time, I need LSB compliance,
I never want it, it is imposed on me.
Just for my information : is the "Requesting
program interpreter: /lib64/ld-lsb-x86-64.so.3 " stuff introduced
to deal with the /lib /lib32 /lib64 non sense of the FHS ?
Acording to
http://wiki.debian.org/Multiarch/TheCaseForMultiarch
The FHS and LSB have standardized the
x86_64 architecture to use /lib64 as
the path for 64-bit x86 libraries, with
/lib reserved for 32-bit x86
libraries on such systems. This is in
spite of the fact that for
performance reasons, x86_64 is the preferred
ABI to use on hardware that
supports it.
Red Hat and SuSE have adopted this standard.
Debian and Ubuntu have
declined to adopt this provision of the
FHS, because the inconsistency
introduced by special-casing of x86_64
would require deep changes to the
packaging tools for incremental benefit.
I fully agree with the Debian position and here is
what I said to the upstream lmutil authors
fp2x@drhpcm05:/tmp$ uname -a
Linux drhpcm05 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32
UTC 2011 x86_64 GNU/Linux
So we have a 64bits binary which does not start on
a Debian stable system, amd64 architecture.
fp2x@drhpcm05:/tmp$ l /etc/ld.so.c*
44 -rw-r--r-- 1 root root 43099 9 juin 16:32
/etc/ld.so.cache
4 -rw-r--r-- 1 root root 34 21
janv. 16:22 /etc/ld.so.conf
/etc/ld.so.conf.d:
total 8
4 -rw-r--r-- 1 root root 68 31 oct. 2010 x86_64-linux-gnu.conf
4 -rw-r--r-- 1 root root 44 9 août 2009
libc.conf
fp2x@drhpcm05:/tmp$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
fp2x@drhpcm05:/tmp$ wc /etc/ld.so.conf.d/*
2 5 44 /etc/ld.so.conf.d/libc.conf
3 5 68 /etc/ld.so.conf.d/x86_64-linux-gnu.conf
5 10 112 total
fp2x@drhpcm05:/tmp$ cat /etc/ld.so.conf.d/libc.conf
# libc default configuration
/usr/local/lib
fp2x@drhpcm05:/tmp$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
fp2x@drhpcm05:/tmp$
I would say that it is a lean and mean system.
fp2x@drhpcm05:/tmp$ l -d /usr/lib*
40 drwxr-xr-x 94 root root 40960 9 juin 16:32
/usr/lib/
4 drwxr-xr-x 3 root root 4096 21
janv. 16:30 /usr/lib32/
0 lrwxrwxrwx 1 root root
3 21 janv. 16:22 /usr/lib64 -> lib/
fp2x@drhpcm05:/tmp$
A 64bits system, with support of 32bits.
Now on a SLES11 system :
fp2x@masime:/tmp> l lmutil
1429 -rwxr-xr-x 1 fp2x users 1461624 déc. 7
2010 lmutil
fp2x@masime:/tmp> ./lmutil lmver -help
lmutil - Copyright (c) 1989-2010 Flexera Software,
Inc. All Rights Reserved.
usage: lmver flexlm_binary
It works !
fp2x@masime:/tmp> l -d /lib*
6 drwxr-xr-x 7 root root 5920 mai 3 17:30
/lib64/
5 drwxr-xr-x 12 root root 4800 mai 3 17:29 /lib/
fp2x@masime:/tmp> ldd ./lmutil
linux-vdso.so.1 =>
(0x00007fff9910e000)
libpthread.so.0 =>
/lib64/libpthread.so.0 (0x00007f3b86f4a000)
libm.so.6 => /lib64/libm.so.6
(0x00007f3b86cf4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1
(0x00007f3b86add000)
libc.so.6 => /lib64/libc.so.6
(0x00007f3b8677f000)
libdl.so.2 => /lib64/libdl.so.2
(0x00007f3b8657b000)
/lib64/ld-lsb-x86-64.so.3
(0x00007f3b87167000)
fp2x@masime:/tmp> l /etc/ld.so.c*
240 -rw-r--r-- 1 root root 244398 mai 9 11:06
/etc/ld.so.cache
4 -rw-r--r-- 1 root root 262 oct.
25 2010 /etc/ld.so.conf
/etc/ld.so.conf.d:
total 16
4 -rw-r--r-- 1 root root 28 juil. 12 2010
ghostscript-omni.conf
4 -rw-r--r-- 1 root root 272 févr. 23 2009 graphviz.conf
4 -rw-r--r-- 1 root root 17 févr. 21 2009
opt_gnome-compat.conf
4 -rw-r--r-- 1 root root 16 juil. 17 2008
NX.conf
fp2x@masime:/tmp>
fp2x@masime:/tmp> wc /etc/ld.so.conf
16 17 262 /etc/ld.so.conf
fp2x@masime:/tmp> cat /etc/ld.so.conf
/usr/X11R6/lib64/Xaw3d
/usr/X11R6/lib64
/usr/lib64/Xaw3d
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib
/usr/lib/Xaw3d
/usr/x86_64-suse-linux/lib
/usr/local/lib
/opt/kde3/lib
/lib64
/lib
/usr/lib64
/usr/lib
/usr/local/lib64
/opt/kde3/lib64
include /etc/ld.so.conf.d/*.conf
fp2x@masime:/tmp>
fp2x@masime:/tmp> wc /etc/ld.so.conf.d/*
1 1 28 /etc/ld.so.conf.d/ghostscript-omni.conf
11 11 272 /etc/ld.so.conf.d/graphviz.conf
1 1 16 /etc/ld.so.conf.d/NX.conf
1 1 17 /etc/ld.so.conf.d/opt_gnome-compat.conf
14 14 333 total
A large number of directories are searched by the
dynamic loader.
fp2x@masime:/tmp> l -d /usr/lib*
68 drwxr-xr-x 151 root root 69480 mai 9 11:07
/usr/lib64/
41 drwxr-xr-x 90 root root 41632 mai 9
11:06 /usr/lib/
fp2x@masime:/tmp>
The system satisfies the requirements of the FHS which
staes :
/lib64 and /lib32 : 64/32-bit libraries (architecture
dependent)
I think that Süse satisfies the letter of the FHS
and Debian statisfuies the spirit of it.
> > How to check which of the 30 packages installs the symlink ?
A symlink do
> > not seem to be listed in the files installed by lsb-core.
>
> The symlinks is created in the post-install script of lsb-core, that's
> why you don't see it in the list of files.
Unfortunately, this introduces a minor bug in dpkg
: (cannot find the package which provides the symlink )
fp2x@drhpcm03:~$ dpkg-query -S /lib64/ld-lsb.so.3
dpkg : /lib64/ld-lsb.so.3 introuvable.
fp2x@drhpcm03:~$ dpkg-query -S /lib/ld-linux.so.2
libc6-i386: /lib/ld-linux.so.2
fp2x@drhpcm03:~$ dpkg-query -S /lib64/ld-linux.so.2
dpkg : /lib64/ld-linux.so.2 introuvable.
fp2x@drhpcm03:~$ dpkg-query -S /lib/ld-lsb.so.3
dpkg : /lib/ld-lsb.so.3 introuvable.
fp2x@drhpcm03:~$ dpkg-query -S /lib64/ld-2.11.2.so
dpkg : /lib64/ld-2.11.2.so introuvable.
fp2x@drhpcm03:~$ dpkg-query -S /lib/ld-2.11.2.so
libc6: /lib/ld-2.11.2.so
fp2x@drhpcm03:~$ dpkg-query -S /lib64
libc6: /lib64
fp2x@drhpcm03:~$ aptitude why libc6-i386
i lsb-core Dépend libc6-i386
fp2x@drhpcm03:~$ aptitude why lsb-core
i python-apt Recommande lsb-release
i A lsb-release Suggère lsb
p lsb Dépend
lsb-core
With all these explanations, we cal close the bug
630411
> --
> Aurelien Jarno
GPG: 1024D/F1BCDB73
> aurelien@aurel32.net
http://www.aurel32.net
Regards,
Cordialement,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
--
F. Petitjean
01 55 24 75 05
Bureau Veritas
Département recherche
1828
A: Because it messes up the order in which people
normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet
and in e-mail?
Reply to: