Side topic: How to link applications agaist non-default OpenSSL builds

On Tue, Jan 27, 2026 at 02:23:48AM -0500, Michael Richardson wrote:

> But, not if you install into a very much non-standard directory (so, not
> /usr/local even).   ./Configure --prefix=$HOME/myjunk etc.

That may be interesting, but not relevant to Ken's original issue, so I
changed the subject header accoringly, if Ken's question is the topic of
interest, please ignore what follows...

> The challenge is that, having installed some shared libraries there,
> convincing other code (your test program) to use those shared libraries can
> be a PITA.   It's possible, it's just easy to wind up with the system
> librairies by mistake.

Also off-topic for Ken's issue, but relevant to this diversion, It is
possible to build libraries with custom "SONAME" strings, so that, once
linked, applications won't accidentally use or conflict with the
system library.  Look for "shlib_variant" in Configurations/README.md.
Thus I have (season to taste):

  ; cat Configurations/99-foo.conf
  my %targets = (
      "linux-x86_64-foo" => {
          inherit_from     => [ "linux-x86_64" ],
          shlib_variant    => "foo",
      },
      "BSD-x86_64-foo" => {
          inherit_from     => [ "BSD-x86_64" ],
          shlib_variant    => "foo",
      },
  );

which after, e.g.

    $ DEST=/opt/openss/master
    $ ./Configure --prefix=$DEST -Wl,-R,$DEST/lib64 \
        enable-fips --prefixlinux-x86_64-foo
    $ make
    $ sudo "make install_sw install_ssldirs install_fips"

gives:

    $ ls -l /opt/openssl/master/lib64/*.so*
    lrwxrwxrwx 1 root root      17 Jan 13 20:01 /opt/openssl/master/lib64/libcrypto.so -> libcryptofoo.so.4
    -rwxr-xr-x 1 root root 7180344 Apr  3  2025 /opt/openssl/master/lib64/libcryptofoo.so.3
    -rwxr-xr-x 1 root root 7323960 Jan 13 20:01 /opt/openssl/master/lib64/libcryptofoo.so.4
    lrwxrwxrwx 1 root root      14 Jan 13 20:01 /opt/openssl/master/lib64/libssl.so -> libsslfoo.so.4
    -rwxr-xr-x 1 root root 1258696 Apr  3  2025 /opt/openssl/master/lib64/libsslfoo.so.3
    -rwxr-xr-x 1 root root 1266776 Jan 13 20:01 /opt/openssl/master/lib64/libsslfoo.so.4

    $ readelf -d /opt/openssl/master/lib64/libcrypto.so | grep -Ew 'SONAME|RUNPATH|NEEDED'
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000e (SONAME)             Library soname: [libcryptofoo.so.4]
     0x000000000000001d (RUNPATH)            Library runpath: [/opt/openssl/master/lib64]

    $ readelf -d /opt/openssl/master/lib64/libssl.so | grep -Ew 'SONAME|RUNPATH|NEEDED'
     0x0000000000000001 (NEEDED)             Shared library: [libcryptofoo.so.4]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000e (SONAME)             Library soname: [libsslfoo.so.4]
     0x000000000000001d (RUNPATH)            Library runpath: [/opt/openssl/master/lib64]

    $ readelf -d /opt/openssl/master/bin/openssl | grep -Ew 'SONAME|RUNPATH|NEEDED'
     0x0000000000000001 (NEEDED)             Shared library: [libsslfoo.so.4]
     0x0000000000000001 (NEEDED)             Shared library: [libcryptofoo.so.4]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000001d (RUNPATH)            Library runpath: [/opt/openssl/master/lib64]

The variant shared libraries avoid conflict with any related system
library symbol versions:

    $ objdump -T /opt/openssl/master/lib64/libcrypto.so | grep '\.text' | head
    00000000000ff5a0 g    DF .text  00000000000001ea  OPENSSLFOO_4.0.0 OSSL_ENCODER_do_all_provided
    0000000000130d50 g    DF .text  00000000000000ab  OPENSSLFOO_4.0.0 EVP_PKEY_get_int_param
    00000000002ca5f0 g    DF .text  0000000000000009  OPENSSLFOO_4.0.0 X509_REVOKED_get_ext_by_critical
    00000000000497e0 g    DF .text  0000000000000005  OPENSSLFOO_4.0.0 BIO_meth_get_puts
    0000000000106480 g    DF .text  000000000000000f  OPENSSLFOO_4.0.0 ESS_CERT_ID_V2_dup
    000000000003b570 g    DF .text  0000000000000095  OPENSSLFOO_4.0.0 ASN1_item_ex_d2i
    00000000000c0a60 g    DF .text  000000000000005b  OPENSSLFOO_4.0.0 DH_security_bits
    00000000002bf1b0 g    DF .text  0000000000000026  OPENSSLFOO_4.0.0 X509_PURPOSE_get_count
    0000000000258440 g    DF .text  0000000000000027  OPENSSLFOO_4.0.0 i2d_RSAPublicKey
    0000000000060fa0 g    DF .text  0000000000000036  OPENSSLFOO_4.0.0 BN_mod_lshift1

Any application linked against these can (just like bin/openssl above)
safely also (dynamically) link with other system libraries that in turn
depend on the system OpenSSL, with the custom and system OpenSSL
libraries coëxising in the same address space without conflict.

Static linking with ".a" libraries is less flexible, and does not
support symbol versions, makes upgrades much less modular, and so I
don't recommend it.

> > To summarize:
> > 
> > - not as root - not installed in the system area - C EVP API, not
> > command line
> 
> As I suggested, build with no-shared, so you get .a files, and link that.
> no-shared != no-dso, and you need dso to be able to load the fips.so (or any
> other provider [or engine] not built in)
> 
> I'm sure a container could help, the challenge is having one with *no* libssl,
> and yet your test code build process still function if it wants to download things.
> Not impossible, but annoying, especially if you then find that you want to
> maybe debug something.

The "sblib_variant" approach is sufficiently robust (on ELF platforms
with SONAMEs and symbol versioning, e.g. Linux and the various BSDs), no
need for containers.  Still off-topic w.r.t. the original question.

The "shlib_variant" approach does not directly extend to MacOS or
Windows, where the runtime linker is substantially different.

-- 
    Viktor.  🇺🇦 Слава Україні!

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/aXh1gjNTnuBRD8dZ%40chardros.imrryr.org.