5

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.

migrated from stackoverflow.com Oct 18 '13 at 1:08

This question came from our site for professional and enthusiast programmers.

  • 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 '13 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 '13 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 '13 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 '13 at 18:29
3

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.

  • 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 '13 at 0:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.