This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17250] static linking breaks nss loading (getaddrinfo/getpwnam/etc...)
- From: "aurelien at aurel32 dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 22 Oct 2014 10:58:54 +0000
- Subject: [Bug libc/17250] static linking breaks nss loading (getaddrinfo/getpwnam/etc...)
- Auto-submitted: auto-generated
- References: <bug-17250-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17250
--- Comment #4 from Aurelien Jarno <aurelien at aurel32 dot net> ---
Looking more at the code the new behaviour is actually wanted. Statically
linked binaries do not lookup in the default lib search patch by default
(DF_1_NODEFLIB is defined as "Ignore default lib search path."):
--- a/elf/dl-support.c
+++ b/elf/dl-support.c
@@ -91,6 +91,7 @@ static struct link_map _dl_main_map =
.l_scope = _dl_main_map.l_scope_mem,
.l_local_scope = { &_dl_main_map.l_searchlist },
.l_used = 1,
+ .l_flags_1 = DF_1_NODEFLIB,
.l_tls_offset = NO_TLS_OFFSET,
.l_serial = 1,
};
This means that the dlopen calls from nss/nsswitch.c do not look for the
default search path. In addition to that it means that the dlopen behavior for
static binaries also has changed and doesn't support loading objects without an
absolute path. This is conform to the POSIX specification ("Otherwise, file is
used in an implementation-defined manner to yield a pathname."), but do we
really want such a behavior change?
Concerning the NSS support we should probably switch it to an absolute path. In
the meantime this can be workarounded by using LD_LIBRARY_PATH
--
You are receiving this mail because:
You are on the CC list for the bug.