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.

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.

@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:

• Brew PR #4308
  • in particular, a bunch of comments referring to CMAKE_PREFIX_PATH for starters
• Brew issue #4293
• Brew issue #4974

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.

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.

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

Hi, I’m here to add a note to @tresf’s observations about this issue.

I’ve maintained the poppler formula in the past and have submitted several updates to the Formula. However, something changed within the past few months and now I’m unable to use brew to build it from source as it always breaks with this include header problem.

The interesting part is that if I download the source myself and then use the same flags the Formula uses to build, it compiles without problem:

$ tar xvf ~/Downloads/poppler-0.78.0.tar.xz 
$ cd poppler-0.78.0/
$ cmake . -DENABLE_UNSTABLE_API_ABI_HEADERS=ON -DBUILD_GTK_TESTS=OFF -DENABLE_CMS=lcms2 -DENABLE_GLIB=ON -DENABLE_QT5=ON -DWITH_GObjectIntrospection=ON
$ make 

Result:

$ ls *dylib*
libpoppler.89.0.0.dylib libpoppler.89.dylib     libpoppler.dylib

I was going to suggest your solution to the poppler team but it appears there’s no need for it outside of home-brew.