Building Tor on Mac OS X Lion

Attached is the log of Tor being compiled with --enable-gcc-warnings during configure on Mac OS X Lion. Looks like Tor works as expected. Thanks to @infowolfe on Twitter for helping with this.

changed milestone to %Tor: 0.2.2.x-final

added component::core tor/tor milestone::Tor: 0.2.2.x-final owner::erinn priority::high resolution::fixed status::closed tor-client type::defect labels

Trac:
tor.log.bz2

This doesn't jive with my experience trying to build Tor on OS X Lion. Perhaps infowolfe and I have different Xcode versions. I installed Xcode 4.1 (4B110) from the App Store after installing Lion.

In any case, Apple seems to have deprecated a boatload of OpenSSL APIs, so Tor fails to build with --enable-gcc-warnings (log attached). For example:

cc1: warnings being treated as errors
crypto.c: In function ‘crypto_log_errors’:
crypto.c:173: warning: ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266)
crypto.c:174: warning: ‘ERR_reason_error_string’ is deprecated (declared at /usr/include/openssl/err.h:283)
crypto.c:175: warning: ‘ERR_lib_error_string’ is deprecated (declared at /usr/include/openssl/err.h:281)
crypto.c:176: warning: ‘ERR_func_error_string’ is deprecated (declared at /usr/include/openssl/err.h:282)

The corresponding function prototype for ERR_get_error(), for example, in /usr/include/openssl/err.h looks like this:

unsigned long ERR_get_error(void) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;

All the other referenced deprecated functions have the same annotation. Indeed, most (if not all) of OpenSSL seems deprecated in Lion:

[edmanm:/usr/include/openssl]$ grep DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER *.h |wc -l
    2667

I have no clue what these have all been deprecated in favor of, though.

Trac:
tor-lion-config.log

OS X Lion / Xcode 4.1 (4B110) / Tor 0.2.3.2-alpha-dev

The only way to get Apple's gcc (llvm-gcc) onto your Lion box is via XCode 4.1 (4B110) which is free on the App Store.

helios:~/Code/tor$ which gcc
/usr/bin/gcc
helios:~/Code/tor$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

You're welcome to compare our versions to verify that yours is the same as mine. I'd really like a look at your config.log, please attach it at your earliest convenience.

Trac:
Username: infowolfe
Cc: N/A to infowolfe+tor@gmail.com

Replying to infowolfe:

You're welcome to compare our versions to verify that yours is the same as mine. I'd really like a look at your config.log, please attach it at your earliest convenience.

There is a tor-lion-config.log attached to this ticket.

If what I asked for was already there, I wouldn't have asked for it. What I want is the config.log file generated automatically by ./configure which is typically located in the same directory as ./configure.

Trac:
Username: infowolfe

My gcc version is identical to yours, but I don't think that's really the most important thing. You could've just looked at your OpenSSL headers in /usr/local/include to see if they had the same DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER declaration on some/all of the API functions. If not, then the question is really how you ended up with weird OpenSSL headers (e.g., maybe messing with MacPorts or something similar). You also have an extra -I/opt/local/include in your gcc output. Perhaps there's another set of OpenSSL headers living in there? In any case, config.log is attached.

Trac:
config.log.bz2

Yup, looks very much like infowolfe is using macports and a macports-provided openssl here.

-- Sebastian

We have a couple of options here. The two acceptable ones I can come up with are: Either we can selectively disable the warning and ignore the deprecation for now, or we can fail during configure and ask people to install an openssl of their own and not use the one shipped with OS X. I am in favor of just disabling the warning, because that means people don't have to hunt for an openssl while their OS still provides one, but I can also see merit in making sure people use their own version of openssl (which would be 1.0x instead of the 0.9x that OS X provides).

nickm?

Trac:
Component: Tor bundles/installation to Tor Client
Milestone: N/A to Tor: 0.2.2.x-final
Type: task to defect
Priority: normal to major

Replying to cypherpunks:

Yup, looks very much like infowolfe is using macports and a macports-provided openssl here.

-- Sebastian

Yah, macports' openssl leaked in with libevent unfortuantely. I'm kinda wondering why edmanm is making noise over something that still isn't technically broken or to be removed immediately. Apple sometimes takes a very long time (10.5 -> 10.6 for instance) to actually act on deprecation notices. Without specifying --enable-gcc-warnings, tor builds fine, macports or not.. and if you add -advisory onto the end like so: "--enable-gcc-warnings-advisory" then the build STILL succeeds and tor still acts as expected.

Anyway, hope to see some of you in Vegas tomorrow. I vote that this bug be closed as "not a bug."

Trac:
Username: infowolfe

Errm. The question was whether or not Tor builds correctly on OS X Lion with --enable-gcc-warnings. Your claim was that it does when in fact that's not true on a standard Lion/Xcode install. I was just pointing out that your claim is not actually true, since you didn't realize you were building with a non-standard OpenSSL (or if you did, you omitted that fact). If that's "making noise", then so be it.

In the short-term, though, yes I do think ignoring it is just fine for now. No claims were made to the contrary.

I say, disable the warnings if possible.

If OSX eventually stops shipping OpenSSL, then we'll need to start saying "first install OpenSSL for OSX" as part of our build instructions, but for now, suppressing the warnings is fine.

Porting to NSS or GnuTLS or whatever would also be ducky, but that's a bigger job for a later date -- possibly much later!

Will put up the patch to disable it once I'm back.

--Sebastian

bug3643 in my repo

Trac:
Status: new to needs_review

looks ok but needs a changes file.

right you are, sorry. Updated.

merging, thanks!

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Keywords: N/A deleted, tor-client added

Trac:
Component: Tor Client to Tor

closed

moved to tpo/core/tor#3643 (closed)