Date: Sun, 27 May 2018 18:42:19 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Antoine Brodin <antoine@freebsd.org> Cc: Jonathan Chen <jonc@chen.org.nz>, freebsd-stable@freebsd.org Subject: Re: ldconfig(8) oddity on 11.2-BETA3? Message-ID: <20180527154219.GR88128@kib.kiev.ua> In-Reply-To: <CAALwa8kUTdN1FV8e5d0oOs5O%2BEKZ_ueKjk5UA16%2BH3%2BEt5GrqQ@mail.gmail.com> References: <CAJuc1zPurH94998BhcHGZOqAu04VV3pNFWnXBq-FknpydNWZqQ@mail.gmail.com> <CAALwa8kUTdN1FV8e5d0oOs5O%2BEKZ_ueKjk5UA16%2BH3%2BEt5GrqQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 27, 2018 at 12:49:12PM +0000, Antoine Brodin wrote: > On Sat, May 26, 2018 at 10:29 PM, Jonathan Chen <jonc@chen.org.nz> wrote: > > Hi, > > > > I'm running 11.2-BETA3/amd64 at r334236, and I've noticed that > > "ldconfig -m" doesn't behave as expected (or perhaps it's my > > understanding). > > > > This is what I'm seeing when building security/nss in a chrooted environment: > > > > # ldconfig -r | grep nss > > # ls /usr/local/lib/nss > > libcrmf.a libnss3.so libnssutil3.so > > libssl3.so > > libfreebl3.so libnssckbi.so libsmime3.so > > libfreeblpriv3.so libnssdbm3.so libsoftokn3.so > > # ldconfig -m /usr/local/lib/nss > > # ldconfig -r | grep nss > > search directories: > > /lib:/usr/lib:/usr/local/lib:/usr/local/lib/perl5/5.26/mach/CORE:/usr/local/lib/nss > > # ldconfig -R | grep nss > > # ldconfig -r | grep nss > > search directories: > > /lib:/usr/lib:/usr/local/lib:/usr/local/lib/perl5/5.26/mach/CORE:/usr/local/lib/nss > > # file /usr/local/lib/nss/*.so > > /usr/local/lib/nss/libfreebl3.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > /usr/local/lib/nss/libfreeblpriv3.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > /usr/local/lib/nss/libnss3.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > /usr/local/lib/nss/libnssckbi.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > /usr/local/lib/nss/libnssdbm3.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > /usr/local/lib/nss/libnssutil3.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > /usr/local/lib/nss/libsmime3.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > /usr/local/lib/nss/libsoftokn3.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > /usr/local/lib/nss/libssl3.so: ELF 64-bit LSB shared object, > > x86-64, version 1 (FreeBSD), dynamically linked, stripped > > > > Is this correct ldconfig behaviour or has something broken? > > > > Hi, > > This looks normal, from the ldconfig(8) man page: > > Filenames must conform to the lib*.so.[0-9] pattern in order to be > added to the hints file. For ELF executable format, ld-elf.so.hints only contains the configured library path. Dynamic linker reads the directories specified there, for typical loading of the library for normally configured case. ldconfig -r does the same, but additionally filters the output by the lib.*\.so\.[0-9]+ patern. Dynamic linker does not filter and uses the name from DT_NEEDED as is.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180527154219.GR88128>