So I'm trying to (re-)compile Tor (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
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.

  • The function EVP_sha256 should be provided by libcrypto.dylib, which is a part of openSSL. What did you use for building openssl? brew? macports? or rolled by hand?
    – Petesh
    Oct 6, 2013 at 17:22
  • 1
    I'm not seeing a -L/usr/local/lib in that link path, so it's trying to use the built-in openSSL. I'd try pointing at the /usr/local openSSL, as I've seen reports of build issues on 10.5 because of issues with the built-in version. Try ./configure --with-openssl-dir=/usr/local
    – Petesh
    Oct 6, 2013 at 17:36
  • 1
    Ah, it looks like the built-in version of openSSL on 10.5 does not supply sha256, which explains the link error. You really do need to link to the copy you built in /usr/local then
    – Petesh
    Oct 6, 2013 at 17:37
  • That didn't quite work, but "./configure --enable-static-openssl --with-openssl-dir=/usr/local" did, which is close enough. You write it up as an answer and I'll accept it. Cheers! :)
    – Ben
    Oct 6, 2013 at 18:29

1 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.


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.


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.

  • Thanks muchly. The worst case scenario with the enable-static options is recompiling tor each time I recompile openssl and that's probably not a bad idea anyway. Awesome answer, have some more points. ;)
    – Ben
    Oct 7, 2013 at 0:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .