thr3ads.net - freebsd stable - ldconfig(8) oddity on 11.2-BETA3? [May 2018]

If this information is useful, please help other people find it:
Share via:

Jonathan Chen

2018-May-26 22:29 UTC

ldconfig(8) oddity on 11.2-BETA3?

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?

Cheers.
-- 
Jonathan Chen <jonc at chen.org.nz>

Eugene Grosbein

2018-May-27 09:26 UTC

head link

ldconfig(8) oddity on 11.2-BETA3?

27.05.2018 5:29, Jonathan Chen wrote:
> 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
No nss in the search path first.
> # 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
Search path updated with addition of /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
This assures update.
> # ldconfig -R | grep nss
ldconfig -R should not produce output, so that's just fine.
> # ldconfig -r | grep nss
>         search directories:
>
/lib:/usr/lib:/usr/local/lib:/usr/local/lib/perl5/5.26/mach/CORE:/usr/local/lib/nss
Still same output as above, still fine.
> # 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?
What exactly you consider to be a problem here?

Antoine Brodin

2018-May-27 12:49 UTC

head link

ldconfig(8) oddity on 11.2-BETA3?

On Sat, May 26, 2018 at 10:29 PM, Jonathan Chen <jonc at 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.

Cheers,

Antoine

freebsd stable - May 2018 - ldconfig(8) oddity on 11.2-BETA3?

ldconfig(8) oddity on 11.2-BETA3?

ldconfig(8) oddity on 11.2-BETA3?

ldconfig(8) oddity on 11.2-BETA3?