Re: bad shared library ordering

>> This isn't what I was alluding to.  Yes, since I discovered this I've
>> deleted the package and I'm rebuilding everything.  Don't even need
>> WITH_OPENSSL_BASE set.  I think the issue is that, perhaps, rpath is
>> being used and so the /usr/local/lib version wins.  If this is the
>case
>> then I see nothing wrong and I just need to do some cleanup.

>I suppose you know about the /etc/ld-elf.so.conf file described in
>section
>FILES of ldconfig(8) manual page ; but the granularity is unfortunately
>per-directory, and I think the only way to link with a specific library
>instead of the first-coming one is to use tricky options of ld(1).  You
>may want to see -l and the -L one.

Sorry Jeremie,

This has nothing to do with /etc/ld-elf.so.conf (which I do not have)
and my /var/run/ld-elf.so.hints is just fine too.  I was observing what
looked like an oddity in how libraries are selected on a correct
system.  It was most likely because some library that kadmin was linking
in had an rpath to /usr/local/lib that was causing libcrypto.so.3 to get
picked up there instead of in /lib.  This is the only think I can think
of.

The proper cure for me was to eliminate the bogus ports install of
openssl.  It would appear the one in base and the ports version are not
compatible.

Cheers,
Sean