Errors that refer to a bunch of unresolved OpenSSL symbols that clearly exist?
Asked Answered
C

1

7

I am building a shared library (we'll call it "foo") that makes use of another library (we'll call it "bar"). "bar" makes use of some functions from OpenSSL.

Here's where the problem surfaces.

"bar" was compiled as a static library and it would appear that OpenSSL was too. So when I link the library ("foo"), I include the:

  • object files for "foo"
  • static library libbar.a
  • OpenSSL static libraries libcrypto.a and libssl.a

The build command looks something like this:

g++ -Wl,-soname,libfoo.so -shared file1.o file2.o libbar.a \
  libcrypto.a libssl.a -o libfoo.so

However, I get a ton of errors:

ld: ./obj/libbar.a(file1.c.o): in function initialize_openssl:
  ssl.c:117: error: undefined reference to 'SSL_library_init'

Running the following command:

nm libssl.a | grep SSL_library_init

Produces the following output:

00000000 T SSL_library_init

So obviously there is nothing wrong with the OpenSSL libraries. What could have possibly caused something like this? Here are the three commands used to build OpenSSL:

export cross=arm-linux-androideabi-
./Configure android --prefix=~/openssl-arm
make CC="${cross}gcc" AR="${cross}ar r" RANLIB="${cross}ranlib"

The compilation process completed without any errors, so I'm utterly baffled.

Why am I getting linker errors that refer to a bunch of OpenSSL symbols that clearly exist?

Casi answered 10/3, 2013 at 4:40 Comment(0)
C
5

The problem was caused by the order of the libraries in the link command. Switching the order of libcrypto.a and libssl.a resolved all of the symbols.

GCC uses LD by default, and its a single pass linker. When you have two libraries, like libssl and libcrypto linked in a particular order, it means libssl depends on symbols from libcrypto. Therefore, libssl must precede libcrypto (or libcrypto must follow libssl). It should be no surprise libssl relies upon libcrypto since libcrypto provides the crypto used by libssl.

Casi answered 10/3, 2013 at 21:34 Comment(1)
I'm guessing because the compiler/linker learn the symbols in a linear order and if an out of order condition happens then it barfs. It could even be reverse-linear (anticipating bar depending on foo and your dependency constructions being built backwards).Sharlasharleen

© 2022 - 2024 — McMap. All rights reserved.