Which directory is the openssldir?
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
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).
You could also run this command to identify in which directory it's installed to.
openssl version -d