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.
I've isolated this to the following change in the
VERBOSE=1 make
logs...-isysroot
command.-isysroot
command.From gnu.org:
So this flag specifically clobbers the
lib
search path only on Apple. This results in the compilation never looking in the standardld
locations, which can be seen by typingld -v dummy
.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:I'm not sure if this is a behavior that warrants an upstream
cmake
patch. If there is a better solution, please provide it.