Which directory is the openssldir? - compilation

Question

When compiling OpenSSL you can add 2 options (from INSTALL in the OpenSSL sources):
Configuration Options
---------------------
There are several options to ./config (or ./Configure) to customize
the build:
--prefix=DIR Install in DIR/bin, DIR/lib, DIR/include/openssl.
Configuration files used by OpenSSL will be in DIR/ssl
or the directory specified by --openssldir.
--openssldir=DIR Directory for OpenSSL files. If no prefix is specified,
the library files and binaries are also installed there.
When compiling other things that rely on OpenSSL or can be added in, an option will be available e.g. for tinc the --with-openssl is available. Should this point to the OpenSSL compilation option given to prefix or openssldir?
Note: I'm not compiling tinc, it's just the first thing I found with a clear example.

Answer 1

You could also run this command to identify in which directory it's installed to.
openssl version -d

Answer 2

which is the openssldir?
By default, the OpenSSL directory is /usr/local/ssl. If you perform a config without --prefix and without --openssldir, that's what you get by default.
Headers will be located in /usr/local/ssl/include/openssl and libraries will be located in /usr/local/ssl/lib.
You should prefer --openssldir, and avoid clever tricks like --prefix=/usr to overwrite a distro's copy of OpenSSL.
If you want to provide a more up to date version of OpenSSL, then look into building a custom package (Personal Package Archive (PPA)) as described at Override Distro Package with Custom Package?.
I'm working on OS X 10.8.5 at the moment. Here's what my /usr/local/ssl looks like (I use one additional directory path on --openssldir due to multiple OpenSSL builds):
$ ls /usr/local/ssl/
android-14 darwin macosx-x64
android-18 ios macosx-x86
the --with-openssl is available. Should this point to the OpenSSL compilation option given to prefix or openssldir?
Yes (but it depends). I've worked with a lot of projects that don't append include and lib properly.
Often times those libraries with --with-openssl are broken in subtle ways. For example, suppose you do the following:
export CFLAGS="-I/usr/local/ssl/include"
export LDFLAGS="/usr/local/ssl/lib"
./config ... --with-openssl=/usr/local/ssl
make
sudo make install
In the above, you will compile and link against the gear in /usr/local/ssl. Then, when you execute your program, it will link against the shared object in /usr/lib, and not the shared object in /usr/local/ssl/lib.
If your distro provides 0.9.8 and you have 1.0.1 in /usr/local/ssl, you will get a lot of unexplained crashes that make no sense. Be vigilant for this issue on OS X because Apple provides 0.9.8.
If you and the distro are both providing something binary compatible (like 1.0.1), then you will be missing functionality without explanation. For example, your version of OpenSSL will have TLS 1.1 and 1.2 enabled, while Ubuntu's version will have TLS 1.1 and 1.2 disabled (Ubuntu priot to 14 built with -DOPENSSL_NO_TLS1_2_CLIENT). And you'll wonder why you cannot connect using TLS 1.2.
If you are compiling on OS X, then you will find OS X silently discards your request to perform static linking (i.e., -Bstatic -lcrypto -lssl). The linker will always use the shared object if available (even on iOS, where its not allowed!). And it will silently ignore your -rpath, too. And forget LD_LIBRARY_PATH because its not honored (you have to use DYLD_LIBRARY_PATH per dyld(1)).
The easiest way to cope with OS X is to:
cd <project>
grep -R "-lcrypto" *
<replace all occurences of -lcrypto with /usr/local/ssl/lib/libcrypto.a>
grep -R "-lssl" *
<replace all occurences of -lssl with /usr/local/ssl/lib/libssl.a>
Archives are just like object files (they are a collection of object files), so you don't even need the -l.
When forcing static linking as above, you don't have to worry about the linker silently discarding your requests or doing things you don't expect. The same works on Linux, too. As a matter of fact, I always use my own version of OpenSSL, and I always do what I described because I got tired of fighting with the various tools (its not only ld, its Eclipse and friends, too).

Answer 3

When compiling other things that rely on OpenSSL, what they usually need is, in order to compile correctly, the openssl binaries - crypto and ssl (linux) - (for linkage) and the include files.
So, your best try would be to point the --prefix you used to install the openssl

Answer 4

https://wiki.openssl.org/index.php/Compilation_and_Installation#PREFIX_and_OPENSSLDIR
PREFIX and OPENSSLDIR
--prefix and --openssldir control the configuration of installed components. The behavior and interactions of --prefix and --openssldir are slightly different between OpenSSL 1.0.2 and below, and OpenSSL 1.1.0 and above.
The rule of thumb to use when you want something that "just works" for all recent versions of OpenSSL, including OpenSSL 1.0.2 and 1.1.0, is:
specify both --prefix and --openssldir
set --prefix and --openssldir to the same location
One word of caution is avoid --prefix=/usr when OpenSSL versions are not binary compatible. You will replace the distro's version of OpenSSL with your version of OpenSSL. It will most likely break everything, including the package management system.