Asked  6 Months ago    Answers:  5   Viewed   88 times

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

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

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

> brew install openssl
==> Downloading
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

and run

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

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.

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/



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:

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

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

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.

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

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

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.

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

Tuesday, June 1, 2021
answered 6 Months ago

I had the same problem after upgrading to Sierra.

In addition to brew --prefix, which displays Homebrew’s install path, there’s also brew --repository, which displays where it’s .git directory is located.

man brew says that claims that “for standard installs, the prefix and repository are the same directory”. Either the man page is out of date or my install isn’t “standard”, but my prefix is /usr/local and my repository is /usr/local/Homebrew.

Using the same command but with cd $(brew --repository) worked for me:

cd $(brew --repository) && git fetch && git reset --hard origin/master
Monday, August 2, 2021
answered 4 Months ago

The GCC documentation tells us that -l is the option to link with a library.

-l library
Search the library named library when linking. (The second alternative with the
library as a separate argument is only for POSIX compliance and is not

So you're telling gcc to link with the libraries "ssl" and "crypto". These libraries are typically installed in /usr/lib. On Linux they'll be called and On OS X they'll be called libssl.dylib and libcrypto.dylib.

Monday, August 2, 2021
answered 4 Months ago

If you define the function in the header file, the compiler will see the function implementation when you build the .exe project and compile a copy of the function code directly into your .exe project. When it is the linker's turn during the build, nothing is missing so the linker is happy and you won't get an error message.

If you define the function in the .cpp file, the compiler will not see the function implementation. It will thus put a reference to the function (i.e. the external symbol) that needs to be resolved later on when it is the linker's turn during the build. To make the linker "see" the external symbol, you need to link your .exe project against your .lib project. Once you have established this link dependency, the linker will be able to find the external symbol and resolve the reference to the function that was earlier generated by the compiler. Because you have a .lib project, which is a static library project, the linker resolves the symbol by grabbing the code for the function from the .lib file and places a copy of the code into your .exe file.

So much for the theory. Now the simplest way to make your .exe project link against your .lib project probably is by adding a reference:

  • In the .exe project's settings, select the section named "Common Properties" at the top of the section list.
  • You should now see a list of references that the .exe project has. The list is probably empty.
  • Click the "Add new reference" button at the bottom of the dialog and add the .lib project as a reference
  • When you select the new reference in the list of references you will see a set of properties for that reference. Make sure that the property called "Link Library Dependencies" is set to true. This will cause the .lib project to be added automatically as an input to the linker when you build the .exe project.

If you build your .exe project, the linker error should now be gone.

Incidentally, by adding the project reference you have also told Visual Studio to build the two projects in the correct order if you build the entire solution: First the .lib project, then the .exe project.

Monday, August 30, 2021
answered 3 Months ago

Not sure why and how but :

rbenv install 2.1.2
rbenv: /usr/local/Cellar/rbenv/versions/2.1.2 already exists
continue with installation? (y/N) y

And now it works ! Just had to reinstall my ruby, like it did re-link openssl with it someway...

I can work again now, but just so I know more what happens, if someone know the under-the-hood mecanisms, I'll be glad to hear it.

Sunday, October 31, 2021
Jeff Yates
answered 1 Month ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :