Tor compiling error - undefined symbols in libor-crypto.a

Question

So I'm trying to (re-)compile Tor 0.2.3.25 (gzipped tarball) on my OS X 10.5.8 system (with GCC 4.0.1) and it's currently dying horribly here:

gcc  -g -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -Wall -fno-strict-aliasing -Wno-deprecated-declarations  -pie -dead_strip -o tor tor_main.o ./libtor.a ../common/libor.a ../common/libor-crypto.a ../common/libor-event.a -lz  -levent -lssl -lcrypto  
Undefined symbols:
  "_EVP_sha256", referenced from:
      _crypto_hmac_sha256 in libor-crypto.a(crypto.o)
  "_EVP_aes_128_ctr", referenced from:
      _aes_new_cipher in libor-crypto.a(aes.o)
  "_RSA_generate_key_ex", referenced from:
      _crypto_pk_generate_key_with_bits in libor-crypto.a(crypto.o)
  "_SHA256", referenced from:
      _crypto_digest256 in libor-crypto.a(crypto.o)
  "_SHA256_Update", referenced from:
      _crypto_digest_add_bytes in libor-crypto.a(crypto.o)
  "_SHA256_Final", referenced from:
      _crypto_digest_get_digest in libor-crypto.a(crypto.o)
  "_SHA256_Init", referenced from:
      _crypto_digest256_new in libor-crypto.a(crypto.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [tor] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I'm assuming I'm going to have to tweak (add?) those symbols in crypto.c and aes.c before trying again, but not being much of a C coder I've got no idea what needs to be changed.

In each of those cases we have another common theme:

ironic:common ben$ pwd
/usr/local/src/tor-0.2.3.25/src/common
ironic:common ben$ cat -n crypto.c | grep _EVP_sha256
ironic:common ben$ cat -n crypto.c | grep EVP_sha256
  1630    HMAC(EVP_sha256(), key, (int)key_len, (unsigned char*)msg, (int)msg_len,
ironic:common ben$ cat -n aes.c | grep _EVP_aes_128_ctr
ironic:common ben$ cat -n aes.c | grep EVP_aes_128_ctr
    99    EVP_EncryptInit(&cipher->evp, EVP_aes_128_ctr(),
   411        /* In openssl 1.0.0, there's an if'd out EVP_aes_128_ctr in evp.h.  If
ironic:common ben$ cat -n crypto.c | grep _RSA_generate_key_ex
ironic:common ben$ cat -n crypto.c | grep RSA_generate_key_ex
   459      if (RSA_generate_key_ex(r, bits, e, NULL) == -1)
ironic:common ben$ 

The same check for "_SHA256" falls over because of the existence of DIGEST_SHA256 in crypto.c, but you get the idea.

Now this has compiled before, but recently I did attempt updating OpenSSL (actually I installed it to /usr/local/bin instead of OS X's default of /usr/bin), but I'm not certain that's related in some way to the current failure to compile. It's possible, but it's equally possible that the /usr/local installation would be ignored entirely in favour of the ancient system default in /usr/bin.

If anyone has encountered this before or has a solution, I'd greatly appreciate it. I'm willing to try fixes which involve patching or modifying the source files (e.g. adding C headers), as long as it isn't modifying the crypto itself.

Answer 1

The errors indicate that the symbols are not present at link time. The symbols listed are ones that are exported by libcrypto, which is a part of OpenSSL; however they are not exposed in the version of openSSL that is shipped in Mac OS X 10.5.

Tor requires sha256 to function correctly, so as a result you need to use an updated version of the OpenSSL library that provides this. This means that you need to specify the path to the OpenSSL library. I would have expected this to be all that is needed; but not having a 10.5 system to test it on, I could not verify it. You need to add the extra option to link in OpenSSL statically, as it doesn't seem to work otherwise; mind you this may be worked around using an RPATH reference passed to the linker.

The final configure command line would read, assuming that openssl was installed into /usr/local/opt/openssl:

./configure --prefix=/usr/local/opt/openssl --enable-static-openssl

This ends up with a final tor compile line that contains a reference to the library directly, thus:

gcc  -g -O2 -D_FORTIFY_SOURCE=2 -Qunused-arguments -fstack-protector-all -Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -Wall -fno-strict-aliasing -Wno-deprecated-declarations -L/usr/local/opt/openssl/lib -L/usr/local/lib -pie -dead_strip -o tor tor_main.o ./libtor.a ../common/libor.a ../common/libor-crypto.a ../common/libor-event.a -lz  -levent /usr/local/opt/openssl/lib/libssl.a /usr/local/opt/openssl/lib/libcrypto.a  

The important piece being the items: /usr/local/opt/openssl/lib/libssl.a and /usr/local/opt/openssl/lib/libcrypto.a, which are the references to the openssl library.

addendum

If you're trying to build a portable version of tor, that doesn't depend on any libraries other than those shipped with the OS, you also need to pass in the --enable-static-libevent flag, as otherwise it will have a dependency on this .dylib as well.

addendum2

Untested, it may work, but I simply don't know...

If you want to try using the shared library, and also make sure that the library is referenced in the run-path of the binary, you need to perform a:

export LDFLAGS=-Wl,-rpath,<directory containing libssl.dylib>:<directory containing libevent.dylib>

before running the configure command, and omit the --enable-static-openssl and --enable-static-libevent command line options. The problem with this, though is that it now means your tor binary depends on these libraries.