Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Incomplete
-
11.7.2, 10.6, 10.11, 11.4
-
None
Description
In the generic linux binary tarballs all binaries and shared libraries should be statically linked against WolfSSL as static linking against OpenSSL is not possible license wise, and dynamic linking can't be used as we do not know what version of OpenSSL is installed on the target server.
Yet when checking library dependencies there are a few results relying on libssl.so.*, and even worse: different versions of it.
E.g.:
mariadb-11.7.2-linux-systemd-x86_64 > ( for a in $(find . -executable -type f); do echo "=== $a ==="; ldd $a 2>/dev/null | grep ssl; echo; done ) | grep -B1 ssl.so
|
=== ./lib/libgalera_smm.so ===
|
libssl.so.1.0.0 => not found
|
--
|
=== ./lib/plugin/hashicorp_key_management.so ===
|
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f06924f0000)
|
--
|
=== ./lib/plugin/ha_s3.so ===
|
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007ff1f7d76000)
|
--
|
=== ./bin/garbd ===
|
libssl.so.1.0.0 => not found
|
--
|
=== ./bin/aria_s3_copy ===
|
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f7dc965a000)
|
Attachments
Issue Links
- relates to
-
-
- Confirmed
-
- links to
Strictly speaking, hashicorp_key_management.so, ha_s3.so, and aria_s3_copy aren't linked with OpenSSL, they're linked with libcurl.so.
It's still a dynamic dependency, though, but I'm not sure what can we do about it. Link with curl statically?
Galera dependencies are handled in MDEV-20394.