Linking not working in homebrew's cmake since Mojave

Question

I've reproduced this symptom on two computers now, cmake seems to no longer look in /usr/local/lib (or more properly, $(brew --prefix)/lib) for Homebrew-provided libraries since upgrading my machine to macOS Mojave.

Although there are ways to circumvent this (e.g. search for homebrew prefix using EXECUTE_PROCESS; add the result to LINK_LIBRARIES(...) command) none are ideal. What changed in Mojave to break this behavior?

The temporary workaround is to add the following to CMakeLists.txt:

# WARNING: Don't hard-code this path
LINK_DIRECTORIES(/usr/local/lib)

I've already tried brew doctor and updated all homebrew packages to no avail.

The specific error that cmake (make) shows is:

ld: library not found for -l<somelib>

I've asked the question on the Homebrew forums and the Apple developer forums.

Dungaree

I found this article explaining how to list the linker search paths using ld -v 2. On High Sierra, it lists /usr/local/lib in the default linker path. Need to compare against Mojave. – Dungaree

... update, Mojave also has /usr/local/lib in the default linker path. – Dungaree

Only after adding VERBOSE=1 to make and comparing the exact linker flags between 10.13 and 10.14 was I able to track it down to a new -isysroot flag being added. Here's a detailed discussion about it on MacPorts trac.macports.org/ticket/57612 – Dungaree

Answer 1

I've isolated this to the following change in the VERBOSE=1 make logs...

• High Sierra (<=10.13) and below did NOT use the -isysroot command.
• Mojave (>=10.14) DOES use the -isysroot command.

From gnu.org:

-isysroot <dir> This option is like the --sysroot option, but applies only to header files (except for Darwin targets, where it applies to both header files and libraries). See the --sysroot option for more information.

So this flag specifically clobbers the lib search path only on Apple. This results in the compilation never looking in the standard ld locations, which can be seen by typing ld -v dummy.

Library search paths:
    /usr/lib
    /usr/local/lib

Why does cmake do this? My thought is it was to fix the /usr/local/include issues introduced with the new Mojave SDK behavior.

Unfortunately, I can't find a cmake compile flag to add the default library search paths back in. For now the only solution I've found is to add the following to my project:

IF(APPLE)
    # Fix linking on 10.14+. See https://stackoverflow.com/questions/54068035
    LINK_DIRECTORIES(/usr/local/lib)
ENDIF()

I'm not sure if this is a behavior that warrants an upstream cmake patch. If there is a better solution, please provide it.

Dungaree

Thanks for this., This is gviing me issue installing wireshark. Where do i add the code? – Cowardly

If you're building from source, I'd guess CMakeLists.txt, but I'm not familiar with the code base. If you're installing from something like MacPorts or Homebrew, it may need to go into a patch file, or perhaps as a submission to the Wireshark codereview process. code.wireshark.org/review/#/q/status:open. Wireshark is super popular so it's probably worthy of a dedicated question here, or on the Wireshark bug tracker. – Dungaree

Answer 2

Ran into a related (?) issue while trying to pip install psycopg2 in a Django app under OS X Mojave (10.14). I was getting the following errors:

ld: library not found for -lssl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'clang' failed with exit status 1

The short explanation: « As of High Sierra, /usr/local is no longer chown-able... »

The solution: change permissions for /usr/local to allow Homebrew to create links.

I adapted the solution to my needs. Then I was finally able to run pip install psycopg2. Here is the sequence of commands (update: inside your project root i.e. where you see manage.py).

First

sudo chown -R $(whoami) $(brew --prefix)/*

Then

brew reinstall openssl
export LDFLAGS="-L/usr/local/opt/openssl/lib"
export CPPFLAGS="-I/usr/local/opt/openssl/include"
pip install psycopg2

Malignancy

Settings LDFLAGS and CPPFLAGS seems to have fixed the issue without chowning /usr/local Mojave 10.14.6 – Saccharide

Thank you! I had this exact same issue. It was driving me crazy. – Unexampled