Cmake linking not working since Mojave


(Tres Finocchiaro) #1

I’ve been maintaining a macOS project for a while and recently with the update to Mojave, cmake no longer can find libraries located in /usr/local/lib.

I’ve been able to work-around the issue by adding the following to CMakeLists.txt

LINK_DIRECTORIES(/usr/local/lib)

… but why is this needed? I’ve been compiling using cmake on 10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13 and this was never needed. Is my environment messed up? If not, what changed?

The symptom surfaces in this particular project as the following error:

ld: library not found for -lfftw3f

Previously cmake would find these libraries automatically.


(Tres Finocchiaro) #2

Cross-linking stackoverflow question: https://stackoverflow.com/q/54068035/3196753


(Sean Molenaar) #3

Is this software distributed through homebrew? Is the cmake instal through homebrew?


(Tres Finocchiaro) #4

Is this software distributed through homebrew?

No, and it never was.

Is the cmake instal through homebrew?

Yes.


(Sean Molenaar) #5

http://cmake.3232098.n2.nabble.com/Odd-Behavior-in-macOS-Mojave-td7598637.html seems to indicate some weird behavior in mojave, but I think the library linking behaviour of cmake on macOS is a bit outside the scope of this forum. It’s not really meant for support with using the software homebrew ships.


(Tres Finocchiaro) #6

Thanks I’ve found that discussion while searching before asking. The linked article is about include not lib, they’re quite different.

On the contrary, this is the ONLY place that people using Homebrew for productivity are allowed to ask questions by like minded developers. It’s a discussion, which is what forums are for. I say this with absolute certainty because the Homebrew bug tracker is intentionally strict and warns NOT to file bug reports. I’ve chosen StackOverflow as an alternate medium but only for the robots.txt (I rarely find community discussion when using search engines).

You can use this place to talk about Homebrew, ask for help or generally anything governed by our Code of Conduct that doesn’t fit on our GitHub repositories. Have fun!

Simply put, if behavior changed with cmake and Homebrew that’s been consistent for many, many years, it needs to be discussed in a medium somewhere. Telling someone that this ISN’T the place without offering an alternate discussion place dismisses the impact to the community – thus dismissing the purpose of a community chat <3.

If this is a nuance with Mojave, it would be nice to have some others help dig and offer information as to why so that projects relying on the old behavior – that valid since at least macOS 10.7 – can write suitable, permanent workarounds for projects.

Somehow, /usr/local/lib was automatically linked prior to Mojave.

Perhaps a better question to this community is… How does Homebrew do it? How does a homebrew .rb formula automatically look in Homebrew for linking at build time? Perhaps that’s the best permanent approach? The cmake formula maintainer may be able to help with this too. Linking Homebrew-provided libraries is very common for C++ projects and custom --prefix detection scripts make the build process more complex.

Finally, 3rd party products using CI services (like Travis-CI, Circle-CI, Jenkins etc) should be affected once they update to Mojave. That’ll probably be the time the majority of people complain. Many projects use Homebrew as dependency management but build on older environments for compatibility reasons.


(Sean Molenaar) #7

I think you’re misunderstanding the purpose of the support homebrew volunteers provide. It’s limited to support for homebrew. It doesn’t extend to the software that you might have installed through homebrew. If something changed in cmake in a specific macOS version my first stop would be a cmake forum, then an apple forum and lastly the homebrew forum since homebrew doesn’t have a lot to do with how cmake and macOS interact.


(Claudia) #8

@tresf I have to agree with what @SMillerDev wrote; this forum is not the right place for CMake support, nor for any other package that happens to be installable through Homebrew.

With that being said: if you really want to learn how Homebrew used to solve CMake-related issues, you may find something in last year’s discussion threads on https://github.com/Homebrew/brew/issues. For example:

Even though CMake questions are off-topic, I hope you’ll find something helpful there to get you started. Feel free to get back in touch with us should any Homebrew-related question come up.


(Tres Finocchiaro) #9

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

This affects any projects using the cmake build system and will be reported again as projects switch to Mojave. Feel free to link here or to the stackoverflow article. Both should have the information needed to explain and workaround this issue.


(Claudia) #10

Thank you @tresf for the writeup, which may be helpful if (and when) those issues come up for other upstream packages. :+1: