After downloading a lsb binary for Linux on architecture amd64 (aka
x_-_64) the
program runs out of the box on a SLES11 machine, but fails on Debian wuth
a cryp
tic message :
fp2x@masime:/tmp> lsb_release --all
LSB Version:
core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:
core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.
0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-
amd64:graphics-4.0-noarch
Distributor ID: SUSE LINUX
Description: SUSE Linux Enterprise Server 11 (x86_64)
Release: 11
Codename: n/a
fp2x@masime:/tmp> ls -lApst lm*
509 -rw-r--r-- 1 fp2x users 516479 juin 9 20:28 lmutil_x64_lsb.tar.gz
464 -rw-r--r-- 1 fp2x users 471556 juin 9 20:28 lmgrd_x64_lsb.tar.gz
1353 -rwxr-xr-x 1 fp2x users 1384304 d├®c. 7 2010 lmgrd
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
fp2x@drhpcm03:/tmp$ lsb_release --all
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.1 (squeeze)
Release: 6.0.1
Codename: squeeze
fp2x@drhpcm03:/tmp$ ls -lApst lm*
1432 -rwxr-xr-x 1 fp2x fp2x 1461624 7 d├®c. 2010 lmutil
fp2x@drhpcm03:/tmp$ ./lmutil
-bash: ./lmutil: Aucun fichier ou dossier de ce type
fp2x@drhpcm03:/tmp$ echo $?
127
extract of readelf -l lmutil
INTERP 0x0000000000000200 0x0000000000400200 0x0000000000400200
0x000000000000001a 0x000000000000001a R 1
[Requesting program interpreter: /lib64/ld-lsb-x86-64.so.3]
program interpreter: /lib64/ld-lsb-x86-64.so.3 is a LSB requirement. For
instance
http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-AMD64/LSB-Core-AMD64/requirements.html
On a patched Debian :
p2x@drhpcm05:/tmp$ lsb_release --all
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.1 (squeeze)
Release: 6.0.1
Codename: squeeze
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
fp2x@drhpcm05:/tmp$ ls -ldp /lib*
drwxr-xr-x 11 root root 12288 10 juin 20:41 /lib/
drwxr-xr-x 2 root root 4096 31 janv. 10:55 /lib32/
lrwxrwxrwx 1 root root 4 21 janv. 16:22 /lib64 -> /lib/
fp2x@drhpcm05:/tmp$ ls -l /lib/ld-lsb-x86-64.so.3
lrwxrwxrwx 1 root root 20 10 juin 20:41 /lib/ld-lsb-x86-64.so.3 ->
ld-linux-x86-64.so.2
fp2x@drhpcm05:/tmp$ ls -l /lib/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 12 31 janv. 10:56 /lib/ld-linux-x86-64.so.2 ->
ld-2.11.2.so
fp2x@drhpcm05:/tmp$ dpkg-query -S /lib/ld-2.11.2.so
libc6: /lib/ld-2.11.2.so
fp2x@drhpcm05:/tmp$ ./lmutil lmver lmutil
lmutil - Copyright (c) 1989-2010 Flexera Software, Inc. All Rights
Reserved.
FLEXnet Licensing v11.9.1.0 build 89952 x64_lsb (liblmgr.a), Copyright (c)
1988-
2010 Flexera Software, Inc. All Rights Reserved.
fp2x@drhpcm05:/tmp$ ./lmutil lmver -help
lmutil - Copyright (c) 1989-2010 Flexera Software, Inc. All Rights
Reserved.
usage: lmver flexlm_binary
So the bug is against the package which provides /lib/ld-2.11.2.so libc6
Severity is not minor because this bug prevents running of a lsb compliant
binary and ldd does not show any missing libraries.
fp2x@drhpcm03:/tmp$ ldd lmutil
linux-vdso.so.1 => (0x00007fffec8a1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f7a2102f000)
libm.so.6 => /lib/libm.so.6 (0x00007f7a20dad000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f7a20b96000)
libc.so.6 => /lib/libc.so.6 (0x00007f7a20835000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f7a20631000)
/lib64/ld-lsb-x86-64.so.3 => /lib64/ld-linux-x86-64.so.2
(0x00007f7a21258000)
fp2x@drhpcm03:/tmp$ ./lmutil
-bash: ./lmutil: Aucun fichier ou dossier de ce type
fp2x@drhpcm03:/tmp$
- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/24 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii libc-bin 2.11.2-10 Embedded GNU C Library:
Binaries
ii libgcc1 1:4.4.5-8 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration
management sy
pn glibc-doc <none> (no description available)
ii locales 2.11.2-10 Embedded GNU C Library:
National L
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.
Aurelien Jarno <aurelien@aurel32.net> a écrit sur 13/06/2011 21:58:51 :
0x0000000000400200
For
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.
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.
Regards
F. Petitjean
All these packages are needed for LSB compliance, either you want LSB compliance or not. 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.
Aurelien Jarno <aurelien@aurel32.net> a écrit le 13/06/2011 à 23:13:45 :
this
/lib64/ld-lsb-x86-64.so.3
libmail-sendmail-perl{a}
mis
dépaquetage,
computations :
a
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.
do
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
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?
close #630411 Hopefully yours F. Petitjean
reassign 630411 lsb-core 3.2-27 retitle 630411 please provide /lib64/ld-lsb-x86-64.so.3 in a smaller package severity 630411 wishlist quit Hi Chris et al, François Petitjean wrote: [...] [...] In other words, on small (embedded?) systems it would be useful to be able to run some LSB binaries without pulling in the entire LSB core. Does that sound like something worth supporting to you? Perhaps we just need some documentation somewhere like the Debian Reference or glibc's README.Debian to explain how people can create the symlink themselves. Anyway, I pass the report to you. :) Thoughts of all kinds welcome. Regards, Jonathan
tags 630411 +wontfix tags 630411 +help thanks Hi François, and thanks for your bugreport, (Thanks to Jonathan for the triaging and summarizing, keep up the good job!) The purpose of LSB is to make a set of interfaces available, amongst which the /lib/ld-lsb.so.* linker symlinks, which don't carry much sense if seen alone. I don't think it's the role of any of the `lsb-` package else than lsb-core to provide those symlinks as they are only a tiny part of what the "LSB interface" is. Furthermore, given admin rights, creating those symlinks is straightforward. So I'm hereby tagging this bug as "wontfix" on the lsb-core package, because I don't think it's glibc's role to document that either. I'm also tagging it "help" as I wouldn't be hostile to review a patch to the packaging that would implement a lsb-core-ld that would take over the symlinks currently handled by lsb-core. Cheers, OdyX
A few points of interest: - the requirements for the dynamic linker symlink are documented in the LSB specification (see refspecs.linuxbase.org for those) - upstream LSB will be working on a solution for pulling in parts of the LSB as part of the 5.0 development effort