Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
3.0.10
-
None
-
None
-
Fedora - all
Description
Disclaimer: I don't understand dynamic linking deep enough, so I need someone to double check after me and also verify, it won't break other distros.
The Cause:
The libmariadb.pc in Fedora looks like this:
Libs: -L${libdir} -lmariadb -lz -ldl -lm -lpthread -lssl -lcrypto
|
While it should look like this:
Libs: -L${libdir} -lmariadb
|
Libs.private: -lz -ldl -lm -lpthread -lssl -lcrypto
|
Now why:
the
-lz -ldl -lm -lpthread -lssl -lcrypto
|
are flags that are used to build the mariadb library, libmariadb.so
The resulting library looks like this:
$ ldd /usr/lib64/libmariadb.so.3 |
linux-vdso.so.1 (0x00007ffd99dbd000)
|
libz.so.1 => /lib64/libz.so.1 (0x00007fd45826e000) |
libdl.so.2 => /lib64/libdl.so.2 (0x00007fd45806a000) |
libm.so.6 => /lib64/libm.so.6 (0x00007fd457cd6000) |
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd457ab7000) |
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fd45784a000) |
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fd4573b9000) |
libc.so.6 => /lib64/libc.so.6 (0x00007fd456ffb000) |
/lib64/ld-linux-x86-64.so.2 (0x00007fd4586d7000) |
There's no need to link against those libraries when you are building against libmariadb.so, because this library already links them.
UPDATE: A good indicator of direct exposure to underlying libraries is if the MariaDB headers have e.g. "#include <openssl/...>" somewhere.
The Issue that can rise is overlinking.
Well explained here: https://wiki.openmandriva.org/en/Overlinking_issues_in_packaging
In practice - have a package that builds against the libmariadb.so library. ( e.g. package
apr-util). Then the produced library will look like this:
$ ldd /usr/lib64/apr-util-1/apr_dbd_mysql.so |
linux-vdso.so.1 (0x00007ffc0a8e0000)
|
libmariadb.so.3 => /lib64/libmariadb.so.3 (0x00007f9c57f1b000) |
libz.so.1 => /lib64/libz.so.1 (0x00007f9c57f01000) |
libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c57efb000) |
libm.so.6 => /lib64/libm.so.6 (0x00007f9c57db5000) |
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9c57d94000) |
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f9c57cfe000) |
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f9c57a1c000) |
libc.so.6 => /lib64/libc.so.6 (0x00007f9c57856000) |
/lib64/ld-linux-x86-64.so.2 (0x00007f9c57f82000) |
But most of those libraries it is linked against, are in fact unsused:
$ ldd -u -r /usr/lib64/apr-util-1/apr_dbd_mysql.so |
Unused direct dependencies:
|
/lib64/libz.so.1 |
/lib64/libdl.so.2 |
/lib64/libm.so.6 |
/lib64/libpthread.so.0 |
/lib64/libssl.so.1.1 |
/lib64/libcrypto.so.1.1 |
The solution is mentioned at the beginning, with the cause.
Split those into "Libs" and "Libs.private".
The libmariadb.pc.in looks like this:
Libs: -L${libdir} -lmariadb @extra_dynamic_LDFLAGS@
|
so the split will be trivial.
Those values are also hardcoded to the mariadb_config. Since more packages use this binary than pkgconfig, it must be fixed also there.
mariadb_config.c.in:
#define LIBS "-L@CMAKE_INSTALL_PREFIX@/@INSTALL_LIBDIR@/ -lmariadb @extra_dynamic_LDFLAGS@"
|
Once fixed in the binary and apr-util package recompiled, the ldd result is clean
$ldd -u -r /usr/lib64/apr-util-1/apr_dbd_mysql.so |
$
|
UPDATE:
This approach work well for environments with dynamic linking. Since with static linking it is necessary to link also all the external libraries.
Changing the mariadb_config might not be a good idea after all.
However it works for Fedora so for now, I'm keeping that patch downstream, until we'll reach some conclusion in this discussion.