Date: Mon, 13 Sep 2004 19:46:41 -0700 From: Sean McNeil <sean@mcneil.com> To: Jeremie Le Hen <jeremie.le-hen@epita.fr> Cc: freebsd-current@freebsd.org Subject: Re: bad shared library ordering Message-ID: <1095130000.1132.9.camel@server.mcneil.com>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1095130000.1132.9.camel>