这是openssldir？

默认情况下，OpenSSL目录 / usr / local / ssl 。如果执行 config 而不使用 - 前缀，而不使用 - openssldir $ c

标题将位于 / usr / local / ssl / include / openssl ，并且库将位于 / usr / local / ssl / lib 中。

- openssldir ，并避免使用 - prefix = / usr 这样聪明的技巧来覆盖发行版的OpenSSL副本。 / p>

如果您想要提供更新版本的OpenSSL，请考虑构建自定义包（个人包存档（PPA）），如覆盖带有自定义包的扩展包？。

OS X 10.8.5。这是我的 / usr / local / ssl 看起来像（我使用一个额外的目录路径 - openssldir 多个OpenSSL构建）：

  $ ls / usr / local / ssl / 
 android-14 darwin macosx-x64 
 android-18 ios macosx-x86 
 

---

--with-openssl可用。这应该是指向前缀还是openssldir的OpenSSL编译选项？

是（但是这取决于）。我已经处理了很多没有正确添加 include 和 lib 的项目。

b
$ b

通常，那些具有 - with-openssl 的库会以微妙的方式被破坏。例如，假设您执行以下操作：

  export CFLAGS = -  I / usr / local / ssl / include
 export LDFLAGS =/ usr / local / ssl / lib
 ./config ... --with-openssl = / usr / local / ssl 
 make 
 sudo make install 
 

在上面，你将编译并链接到 / usr / local / ssl 。然后，当你执行程序时，它将链接到 / usr / lib 中的共享对象，而不是 / usr / local中的共享对象/ ssl / lib 。

如果你的发行版本提供了0.9.8，而你在 / usr / local / ssl ，你会得到很多不明原因的崩溃，没有意义。在OS X上警告这个问题，因为苹果提供了0.9.8。

如果你和发行版都提供二进制兼容（如1.0.1）将缺少功能没有解释。例如，您的OpenSSL版本将启用TLS 1.1和1.2，而Ubuntu的版本将禁用TLS 1.1和1.2（使用 -DOPENSSL_NO_TLS1_2_CLIENT 构建Ubuntu priot 14）。你会想知道为什么你不能使用TLS 1.2连接。

如果你在OS X上编译，那么你会发现OS X默默地丢弃你的请求执行静态链接（即 -Bstatic -lcrypto -lssl ）。链接器将始终使用共享对象（如果可用）（即使在iOS上，不允许！）。它也会默认忽略你的 -rpath 。并且忘记了 LD_LIBRARY_PATH ，因为它没有兑现（你必须使用 DYLD_LIBRARY_PATH 每 dyld（1） a>）。

处理OS X的最简单的方法是：

  cd< project> 
 grep -R-lcrypto* 
<将所有出现的-lcrypto替换为/usr/local/ssl/lib/libcrypto.a> 
 grep -R-lssl* 
<将所有出现的-lssl替换为/usr/local/ssl/lib/libssl.a> 
 

档案就像对象档案（它们是对象档案的集合）甚至需要 -l 。

当强制执行静态链接时，你不必担心链接器默默地丢弃你的请求或做你不期望的事情。在Linux上也是一样。事实上，我总是使用我自己的版本的OpenSSL，我总是做我所描述的，因为我厌倦了与各种工具（它不仅 ld ， Eclipse 和朋友）。

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.

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).