4 ms·
Why are libraries written in this way? Seems fairly insane to expose parts of another library as a part of your public interface. It's not necessarily intentio
by cperciva 10y ago
Why are libraries written in this way? Seems fairly insane to expose parts of another library as a part of your public interface.
It's not necessarily intentional. One of the more "interesting" bugs we've seen in FreeBSD was when a program linked to libraries A and B, and library A linked to libcrypto (openssl) while library B linked to libmd (a lightweight hash function library).
Each part worked fine independently, but when it was all put together, the dynamic linker said "we need to find an object called SHA256_Init? Oh look, it's in this library we already loaded!" with predictably hilarious results. (We now use preprocessor macros to define _libmd_SHA256_Init etc. to avoid such linker confusion.)
What you think your public interfaces are and what the linker thinks your public interfaces are don't necessarily align.
- rkeene2 10y agoSymbol versioning can solve this at the linker layer without modifying the source. One possibility is to use --default-symver when compiling OpenSSL and libmd, then when they are linked the appropriately the soname is used as a version tag for any unversioned symbols. An example: http://www.rkeene.org/viewer/tmp/linking-troubles/log.html.htm http://www.rkeene.org/viewer/tmp/linking-troubles/log.html.h... If you are a library maintainer and export a stable ABI, it might also be good to provide a version or every symbol if for no other reason than to avoid issues with the flat namespace.