A few days ago I discovered that sometimes applications will reference a symbol and a version when attempting to link to an application. Usually an undefined symbol is related to one of the following:
- A library required to link
- Improper linking order
- The symbol not being within the library at all
As a I discovered, this is not always the case:
-
libtool: link: g++ -I/usr/include/openssl -o .libs/md5_test tests/md5_test.o -L/usr/lib /usr/lib/libACE_SSL.so /usr/lib/libACE.so -lpthread ../libeap/.libs/libeap.so ../libeap/.libs/libeaparchie.so ../libeap/.libs/libeapgpsk.so -lboost_system -lboost_thread /usr/lib/libACEXML.so /usr/lib/libACEXML_Parser.so -ldl -lssl -lcrypto
-
../libeap/.libs/libeap.so: undefined reference to `MD5@OPENSSL_1.0.0'
-
../libeap/.libs/libeap.so: undefined reference to `RAND_bytes@OPENSSL_1.0.0'
-
collect2: ld returned 1 exit status
The above code shows libssl and libcrypto being linked correctly, however there are undefined symbols to both MD5 and RAND_bytes. Interestingly enough, there is also an @version appended; for why or how - I don't know. Perhaps someone could comment - this is using 1.0.0m.
After further investigation, I discovered this very interesting predicament - openssl 1.0.0m when compiled with this command: ./config --prefix=/usr --openssldir=/etc/ssl --libdir=lib shared
Generates two sets of shared objects located in:
-
/usr/lib/x86_64-linux-gnu/
-
/usr/lib
The shared objects in /usr/lib/x86_64-linux-gnu/ Produce a version (used objdump -T)
00000000001546b0 g DF .text 0000000000000108 OPENSSL_1.0.0 PKCS7_to_TS_TST_INFO
The shared objects in /usr/lib produce this:
000000000012ee20 g DF .text 000000000000000c Base BIO_new_CMS
As a solution to think linking error - I linked to the libraries in /usr/lib/x86_64-linux-gnu/ I assume this is not very elegant, but it works. If you know of this or what fixes this issue, please comment!
Add new comment