Re: OpenSSL 1.1.1 libssl.so version number

> On Oct 14, 2018, at 2:00 AM, Don Lewis <truckman_at_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