Untange kludgey library detection, particularly for SSL forks
Split from #13415 (moved):
teor:
LibreSSL
I'm having trouble getting LibreSSL (2.1.2) to work with tor git on OS X 10.9.
Here are the issues I've found and fixed in the configure invocation:
configure --with-openssl-dir= detects the wrong bin/openssl if "$OPENSSL_DIR/bin/openssl" isn't in the path before all other openssl executables.
configure --enable-static-openssl requires LDFLAGS="$OPENSSL_DIR/lib":$LDFLAGS to link properly, at least on OS X. I'm pretty sure these issues will affect all (non-system/non-standard) SSLs.
Can we make configuring with non-system SSLs easier by prepending "$OPENSSL_DIR/bin" and "$OPENSSL_DIR/lib" to the PATH and LDFLAGS respectively?
BoringSSL
BoringSSL is even worse - it doesn't even have an openssl executable, only builds static libraries, and is a pain to configure correctly under our current config scripts.
I can't seem to stop it finding the system-supplied SSL, even when I provide it the BoringSSL directories.
I get the following warnings when I manually install BoringSSL into include/lib/bin dirs, and fake the openssl executable using the bssl executable:
(See #13815 (moved))
nickm:
(The build issues are another matter and should get their own ticket: Untangling our kludgey library detection has been something a bunch of people have wanted for a while.)