Add link directories in CMakeList for MacOs and HomeBrew

[tbaudier]

Link to lfreetype

With MacOS 11 Big Sur, the link during the compilation of Gate failed with:

[100%] Building CXX object CMakeFiles/Gate.dir/Gate.cc.o
[100%] Linking CXX executable Gate
ld: library not found for -lfreetype
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Gate] Error 1
make[1]: *** [CMakeFiles/Gate.dir/all] Error 2
make: *** [all] Error 2

libfreetype is installed by Homebrew in /usr/local/lib and detected by Cmake during configuration. I proposed the solution you can find here https://github.com/opencv/opencv_contrib/issues/1446 and https://github.com/opencv/opencv/blob/3.3.1/cmake/OpenCVCompilerOptions.cmake#L343-L345 Can someone test is with previous version of MacOs, please?

[nkrah]

Thanks Thomas for reporting.

I have been banging my head over the same problem on my Mac (running MacOS 11.1, BigSur). I think the problem is related to the way the library search path is now handled. CMake seems to prepend the MacOS versions specific root path with this option: -syslibroot <SYSLIBROOT> which in my case is /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk

The linker itself knows about /usr/local/lib, which can be checked by clang -Xlinker -v but since there is no SYSLIBROOT/usr/local/lib, i.e. with the prefix prepended, this search path gets dropped and the linker ignores it.

In the specific case, freetype seems to be a library needed by ROOT, which in turn is needed by Gate. What seems strange to me is that my ROOT is compiled with BUILTIN_FREETYPE, so should have its own version of freetype. So I do not fully understand why this is not picked up when configuring the Gate install. Or in other words: it does not seem clean if ROOT itself has its own builtin freetype, but then Gate links against an external version (e.g. the Brew one). Maybe someone more expert than myself can shed light on this? @djboersma : Did you not mention something about libfreetype lately at a Gate technical meeting?

Otherwise I agree with @mojca : would be better to avoid explicit paths.

[nkrah]

Here is a related CMake issue that explains the situation I mentioned above regarding dropped /usr/local/XXX directories. The issue refers to implicit include paths, but I guess it's fairly analogous to lib paths as well.

https://gitlab.kitware.com/cmake/cmake/-/issues/19120

[nkrah]

Quick follow-up: The above described error occurred while I was using a version of ROOT compiled within my home when compiling Gate. I now used ROOT installed via brew, i.e. ROOT 6.22.06_2. Compiling of Gate with this succeeds. Specifically, in ccmake, I specified: ROOTCINT_EXECUTABLE /usr/local/bin/rootcint
ROOT_CONFIG_EXECUTABLE /usr/local/bin/root-config

I do not fully understand what is going on, but the freetype libraries used by ROOT seems to be picked up correctly now when compiling Gate.

@tbaudier : Have you used brew's ROOT? which version? or a hand-compiled one?

[nkrah]

And one comment more: Geant4 also links against libfreetype, in my case against /usr/local/lib/libfreetype.dylib. So Gate's dependency on Geant4 might explain the failed linking when compiling Gate. BUT: I observed the same linking problem with another software which depends on ROOT but not on Geant4. Therefore I think the problem lies in the dependency of Gate on ROOT.