In message <[email protected]>, Daniel Eischen w rites: > > > > On Oct 12, 2018, at 10:58 PM, Cy Schubert <[email protected]> wrote > : > > > > In message <[email protected]>, Don Lewis writes: > >> 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. > > > > This is also the issue with ports-mgmt/pkg on a system that still > > requires OpenSSL 1.0.2 from ports in order to support an old client. > > > > cwfw# pkg info > > 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 > > cwfw# > > > > If I remove security/openssl, the above issue is resolved however the > > old client, which should be replaced next year, fails to communicate > > with the server. The classic rock & a hard place scenario. > > Not saying this is a real solution for the general problem, but can you use a > libmap.conf entry to work around this?
I tried using the path1 path2 form. No joy there. -- Cheers, Cy Schubert <[email protected]> FreeBSD UNIX: <[email protected]> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]"
