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-...@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