Also affects "pkg" (was: Re: OpenSSL 1.1.1 libssl.so version number)

Am 13.10.18 um 01:56 schrieb Don Lewis:
> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> is ambiguous because there are now two different versions of libssl.so
> (1.0.2p and 1.1.1) with the same shared library version number.
> 
> I stumbled across this when debugging a virtualbox-ose configure
> failure.  The test executable was linked to the ports version of
> libssl.so but rtld chose the base libssl.so at run time.

I'm seeing something possibly related in pkg:

$ ldd /usr/local/lib/libpkg. | grep ssl
libpkg.a         libpkg.so        libpkg.so.4      libpkg.so.4.0.0

$ldd /usr/local/lib/libpkg.so.4 | grep ssl
	libssl.so.9 => /usr/lib/libssl.so.9 (0x800679000)

This results in:

$ pkg -v
ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 required by
/usr/local/lib/libpkg.so.4 not defined

My work-around was to copy pkg-static over pkg (I have not checked
whether the static version is linked against the system or ports
version of the library, but I assume the latter).

I have "DEFAULT_VERSIONS+= ssl=openssl" in make.conf but the same
problem exists if pkg is built without that setting.

My local version of portmaster has been changed to use pkg-static
in favor of pkg and I plan to commit that change to the portmaster
port, to make it resilient against this problem.

Regards, STefan