自制程序拒绝链接OpenSSL [英] Homebrew refusing to link OpenSSL

问题描述

我正在使用:OSX 10.11.6，Homebrew版本0.9.9m OpenSSL 0.9.8zg，2015年7月14日

I'm on: OSX 10.11.6, Homebrew version 0.9.9m OpenSSL 0.9.8zg 14 July 2015

我正在尝试使用dotnetcore并遵循其说明，

I'm trying to play with with dotnetcore and by following their instructions,

我已经升级/安装了最新版本的openssl:

I've upgraded/installed the latest version of openssl:

> brew install openssl
==> Downloading https://homebrew.bintray.com/bottles/openssl-1.0.2h_1.el_capitan.bottle.tar.gz
Already downloaded: /Users/administrator/Library/Caches/Homebrew/openssl-1.0.2h_1.el_capitan.bottle.tar.gz
==> Pouring openssl-1.0.2h_1.el_capitan.bottle.tar.gz
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /usr/local/etc/openssl/certs

and run
  /usr/local/opt/openssl/bin/c_rehash

This formula is keg-only, which means it was not symlinked into /usr/local.

Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/openssl/lib
    CPPFLAGS: -I/usr/local/opt/openssl/include

但是当我尝试链接openssl时，我继续遇到此链接错误:

But when I try to link openssl I continue to run into this linking error:

> brew link --force openssl
Warning: Refusing to link: openssl
Linking keg-only OpenSSL means you may end up linking against the insecure,
deprecated system version while using the headers from the Homebrew version.
Instead, pass the full include/library paths to your compiler e.g.:
  -I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib

包括编译器标志的选项对我来说没有意义，因为我没有编译我依赖的这些库.

The option to include compiler flags doesn't make sense to me, since I'm not compiling these libraries that I'm dependent on.

编辑 dotnetcore已更新其说明:

EDIT dotnetcore has updated their instructions:

brew update    
brew install openssl    
ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/    
ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/

推荐答案

正如其他答案的更新所述，安装旧的openssl101 brew的解决方法将不再起作用.有关当前的解决方法，请参见在dotnet/cli#3964 上的评论.

As the update to the other answer suggests, the workaround of installing the old openssl101 brew will no longer work. For a right-now workaround, see this comment on dotnet/cli#3964.

与问题最相关的部分复制到此处:

The most relevant part of the issue copied here:

我研究了建议在库中设置rpath的另一个选项.我认为以下是仅会影响此特定库的更好的解决方案.

I looked into the other option that was suggested for setting the rpath on the library. I think the following is a better solution that will only effect this specific library.

sudo install_name_tool -add_rpath /usr/local/opt/openssl/lib /usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Security.Cryptography.Native.dylib

和/或(如果您已安装NETCore 1.0.1)也对1.0.1执行相同的命令:

and/or if you have NETCore 1.0.1 installed perform the same command for 1.0.1 as well:

sudo install_name_tool -add_rpath /usr/local/opt/openssl/lib /usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.1/System.Security.Cryptography.Native.dylib

实际上，我们不是在告诉操作系统始终使用SSL的自制版本并可能造成某些问题，而是告诉dotnet如何找到正确的库.

In effect, rather than telling the operating system to always use the homebrew version of SSL and potentially causing something to break, we're telling dotnet how to find the correct library.

同样重要的是，微软似乎已经意识到了这一问题，并且都具有a)缓解的近期计划以及b)长期的解决方案(可能将OpenSSL与dotnet捆绑在一起).

Also importantly, it looks like Microsoft are aware of the issue and and have both a) a somewhat immediate plan to mitigate as well as b) a long-term solution (probaby bundling OpenSSL with dotnet).

要注意的另一件事:/usr/local/opt/openssl/lib是默认情况下链接Brew的位置:

Another thing to note: /usr/local/opt/openssl/lib is where the brew is linked by default:

13:22 $ ls -l /usr/local/opt/openssl
lrwxr-xr-x  1 ben  admin  26 May 15 14:22 /usr/local/opt/openssl -> ../Cellar/openssl/1.0.2h_1

如果出于任何原因安装了brew并将其链接到其他位置，则该路径就是您应该用作rpath的路径.

If for whatever reason you install the brew and link it in a different location, then that path is the one you should use as an rpath.

一旦更新了System.Security.Cryptography.Native.dylib libray的rpath，就需要重新启动交互式会话(即，关闭控制台并启动另一个会话).

Once you've update the rpath of the System.Security.Cryptography.Native.dylib libray, you'll need to restart your interactive session (i.e., close your console and start another one).

这篇关于自制程序拒绝链接OpenSSL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！