DD4hep not working on El Capitan and MacOS Sierra

[petricm]

Due to the System Integrity Protection (SIP), as well as preventing anyone from modifying system files, protected binaries no longer inherit linker environment variables. Meaning that setting the DYLD_LIBRARY_PATH will have no effects on spawned sub shells unless one turns off (SIP).[1][2]

[petricm]

Just as reference Aliroot does not work either on El Capitan and Sierra [1], due to the same reasons and they suggest turning off SIP.

[petricm]

One more addition, any system binary in: /bin /sbin /usr /System will exhibit striping of DYDL_* however, except for /usr/local. Which mean if you copy /bin/sh /bin/bash /usr/bin/env to some custom location and add it at the beginning of PATH, you will partially get back the desired behavior.

Normal SIP behavior: $ (export DYLD_FOO=foo; env) | grep foo $ with binaries copied to new location and added to path $ (export DYLD_FOO=foo; env) | grep foo $ dyld: warning, unknown environment variable: DYLD_FOO $ DYLD_FOO=foo

This still does not resolve the build problem, but might help.

[petricm]

The above fix does not work, because MakeRootMap calls EXECUTE_PROCESS, and this does not really open a new shell, but executes the child process using operating system APIs directly. All arguments are passed VERBATIM to the child process. Thus no intermediate shell is used.

[petricm]

Just a small update on this. The problem from the DD4hep side has been resolved, we can now "propagate" the DYLD_LIBRARY_PATH, however this only uncovered a problem in CLHEP cmake config, which does not set rpath.

[petricm]

The description of the underlying problem https://its.cern.ch/jira/browse/CLHEP-139

[gaede]

Did you try and build CLHEP with cmake -D CMAKE_MACOSX_RPATH=ON ..

[petricm]

I wanted to answer you yes, that it is set ON since there was no policy warning from CMake and by default it should be ON as described here, but they do this in their CMakeList.txt

if(POLICY CMP0042)
  cmake_policy(SET CMP0042 OLD)
endif()

So it is OFF. Will check how things get affected.

[petricm]

Does not help. I have recompiled CLHEP there are some changes in the cmake config, then I recompiled also Geant4. But this does not get propagated to the linking of e.g. libDDG4Plugins.dylib

/Library/Developer/CommandLineTools/usr/bin/c++ -W -Wall -pedantic -Wno-non-virtual-dtor -Wno-long-long -Wwrite-strings -Wpointer-arith -Woverloaded-virtual -Wno-variadic-macros -Wshadow -pipe -Qunused-arguments -stdlib=libc++ -DG4USE_STD11 -std=c++11 -std=c++11 -ftls-model=global-dynamic -Wall -Wextra -pedantic -Wshadow -Wformat-security -Wno-long-long -Wdeprecated -O2 -DNDEBUG -O3 -DNDEBUG -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -compatibility_version 0.19.0 -current_version 0.19.0 -o ../lib/libDDG4Plugins.0.19.dylib -install_name @rpath/libDDG4Plugins.0.19.dylib ...... /cvmfs/clicdp.cern.ch/software/CLHEP/2.3.1.1/x86_64-mac1012-clang80-opt/lib/libCLHEP.dylib ..... -Wl,-rpath,/cvmfs/clicdp.cern.ch/software/ROOT/6.08.00/x86_64-mac1012-clang80-opt/lib -Wl,-rpath,/Users/lcdci/test/DD4hep/build/lib -Wl,-rpath,/cvmfs/clicdp.cern.ch/software/Geant4/10.02.p02/x86_64-mac1012-clang80-opt/lib We would need at the end an additional -Wl,-rpath,/cvmfs/clicdp.cern.ch/software/CLHEP/2.3.1.1/x86_64-mac1012-clang80-opt/lib

But I don't know what is the cause of the issue, either CLHEP is the problem, they don't set rpath or they do and Geant4 config cmake does not propagate correctly.

[petricm]

Hi, good news, it's a CLHEP cmake problem, which is resolved in CLHEP 2.3.3.2 (report form @peterkostka) and I also tested with 2.3.4.2 and it works. Now you have: @rpath/libCLHEP-2.3.4.2.dylib (compatibility version 0.0.0, current version 0.0.0) It is not optimal, since this version of CLHEP is not officially endorsed by Geant4, but should be resolved once Geant4 10.3 comes out, for now I have updated the CI with the new version of CLHEP.

There is still some work, hopefully minor, to propagate the DD4HEP_LIBRARY_PATH to all corners...

[gaede]

Hi Marko, indeed good news. I don't think it is a problem if people using the latest macos switch to a slightly newer CLHEP version. No one is doing production on a Mac - and for official ilcsoft releases we stay with CLHEP 2.3.1.1 which is officially endorsed by the Geant4 folks.