Bug#817988: marked as done (libc6-dev: libm.so no longer a symlink in 2.22-2 ; break dlopen() in mpi4py)
Your message dated Sat, 12 Mar 2016 14:32:45 +0100
with message-id <20160312133245.GA32501@aurel32.net>
and subject line Re: Bug#817988: libc6-dev: libm.so no longer a symlink in 2.22-2 ; break dlopen() in mpi4py
has caused the Debian Bug report #817988,
regarding libc6-dev: libm.so no longer a symlink in 2.22-2 ; break dlopen() in mpi4py
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
817988: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817988
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libc6-dev
Version: 2.22-2
Severity: serious
Justification: Policy 8.4
/usr/lib/$ARCH/libm.so is no longer a symlink in 2.22-2, thus breaking packages
which try to use it.
In particular, mpi4py dynamically links libm.so leading an FTBFS #817884
>>> from mpi4py import dl
>>> libm='libm.so'
>>> handle = dl.dlopen(libm, dl.RTLD_LOCAL|dl.RTLD_LAZY)
>>> dl.dlerror()
'/usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header'
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libc6-dev depends on:
ii libc-dev-bin 2.19-18+deb8u3
ii libc6 2.19-18+deb8u3
ii linux-libc-dev 3.16.7-ckt20-1+deb8u4
libc6-dev recommends no packages.
Versions of packages libc6-dev suggests:
pn glibc-doc <none>
ii manpages-dev 3.74-1
-- no debconf information
--- End Message ---
--- Begin Message ---
On 2016-03-12 13:10, Bastian Blank wrote:
> On Sat, Mar 12, 2016 at 11:51:32AM +0000, Alastair McKinstry wrote:
> > /usr/lib/$ARCH/libm.so is no longer a symlink in 2.22-2, thus breaking packages
> > which try to use it.
>
> *.so is for use by ld, and is a linker script in this case. It have
> been the case for libc.so for ages.
Correct. /usr/lib/$ARCH/libm.so should not be used for dlopen() and in
general loading the .so directly is wrong, as the ABI can change.
> > In particular, mpi4py dynamically links libm.so leading an FTBFS #817884
>
> Dynamic linking uses the _abiname_, which is libm.so.6 in this case, but
> is may be libm.so.6.1 or libm.so.0.3 in other cases.
Indeed. The correct way to do that is the following:
#include <gnu/lib-names.h>
handle = dlopen(LIBM_SO, options);
I am therefore closing the bug as invalid.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
--- End Message ---
Reply to: