Re: Bug#826906: uid-wrapper: FTBFS[!linux]: only supports libc.so.[0-9] filename
Hi!
On Fri, 2016-06-10 at 02:20:15 +0100, Steven Chamberlain wrote:
> Package: uid-wrapper
> Version: 1.2.0+dfsg1-1
> Severity: normal
> Tags: patch
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
> I found this happens because src/uid_wrapper.c doesn't detect the libc's
> filename. It matches libc.so.[0-9] whereas on kfreebsd it is named
> libc.so.0.1 currently.
>
> The same problem will affect hurd too, which has libc.so.0.3 (although
> there are other reasons for FTBFS on hurd).
>
> Please consider the attached patch to detect libc.so.0.[0-9] as well.
> Unless there is some neater way to do this. Thanks a lot!
Yeah, I think the initial approach is just wrong. Consider if we ever
had an (unlikely) SONAME bump for libc, the library might end up linked
against libc.so.7 and the code loading libc.so.6. Depending on the
intended usage there are possibly better ways to achieve that.
If the library is supposed to be pre-loaded then using RTLD_NEXT as
the handle is way better, and avoids having to use an explicit library
name.
If it's not, on GNU systems we can always use LIBC_SO and LIBPTHREAD_SO
from <gnu/lib-names.h>, for example. Otherwise on non-GNU ELF systems,
we could link a small program and then readelf (or objdump) it to find
the NEEDED entry for libc. Or we could also try to readlink the libc.so
symlink and make sure it's an ELF object at build time to try to get the
SONAME (this will fail on at least GNU systems as the libc.so is a linker
script there).
Thanks,
Guillem
Reply to: