> On Oct 14, 2018, at 2:00 AM, Don Lewis <truck...@freebsd.org> wrote:
>
>> On 12 Oct, Don Lewis wrote:
>> 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.
>
> It looks to me like the base libssl.so version needs to get moved to a
> value that doesn't collide with ports, perhaps 12. These are the
> library version numbers currently used by the various ssl ports:
Even if base OpenSSL used 12, don't you potentially have the same problem if
the port bumps their version sometime later?
And do you have a problem if a port library is built against a port OpenSSL,
and another port library is built against base OpenSSL, then an app links to
both libraries, getting both base and port OpenSSL's linked in the same image?
It seems like you have to ensure that when you specify WITH_OPENSSL, that all
your ports are [re]built this way, no? I guess base OpenSSL is really no
different, all ports need to be built using the same library, whether it's base
or some other port version.
--
DE
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
