On Fri, Jun 30, 2023 at 09:26:47AM -0400, Viktor Dukhovni wrote: > > But > > the process can also load dynamically (via configuration) database > > client drivers installed on a computer. (Mainly to perform secure > > connection with the database engine). But those database drivers are > > linked with the openssl version of the system. That is mainly openssl > > version 1.1. > > See: > > https://github.com/openssl/openssl/blob/55d3a6be6ba3af9781631e74833ea1dcbd4008e6/Configurations/README.md?plain=1#L129-L149 > > This allows you to: > > - Not have to resort loading the custom libssl at runtime, you > can just use a shared library. > > - Avoid conflicts even with a slightly different system libssl > that has the same major version. > > Choose the variant name carefully, something related to your > company or product, not likely to be chosen by another package. Since you're getting three conflicting responses, I should perhaps explain that the "Configure" option "shlib_variant=<...>" was specifically designed to address use of multiple OpenSSL shared library versions within a single process. On ELF-based systems, it works provided symbol versions are supported by the runtime link editor (ld.so), and that OpenSSL is not also linked in statically. If you link OpenSSL into a wrapper shared library of your own, and don't export the OpenSSL symbol from that shared object, that'll also work, but takes more work to implement. And of course, as Matt noted, some care is required, so all three answers are right in their own way. -- Viktor.
