Skip to content

Conversation

@sethrj
Copy link

@sethrj sethrj commented Dec 23, 2025

BEGINRELEASENOTES

  • Use the ROOT_LIBRARY_PATH environment variable inside add_dd4hep_plugin
  • Cache ROOT_LIBRARY_PATH and (DY)LD_LIBRARY_PATH for reproducibility across builds
    ENDRELEASENOTES

See spack/spack-packages#2875 : newer versions of ROOT require the ROOT_LIBRARY_PATH at runtime. Without this change, the plugin creation fails:

cd /Users/seth/Code/celeritas-temp/build/src/ddceler && /opt/homebrew/bin/cmake -E env DYLD_LIBRARY_PATH=/Users/seth/Code/celeritas-temp/build/lib:/opt/spack/var/spack/environments/celeritas/.spack-env/view/lib: /opt/spack/var/spack/environments/celeritas/.spack-env/view/bin/listcomponents_dd4hep -o libDDcelerRunAction.components libDDcelerRunAction.dylib
Error in <UnknownClass::FindDynamicLibrary>: libRIO[.so | .dll | .dylib | .sl | .dl | .a] does not exist in /Users/seth/Code/celeritas-temp/build/lib:/opt/spack/var/spack/environments/celeritas/.spack-env/view/lib::::.:/usr/local/lib:/usr/X11R6/lib:/usr/lib:/lib:/lib/x86_64-linux-gnu:/usr/local/lib64:/usr/lib64:/lib64:
Error in <UnknownClass::FindDynamicLibrary>: libCling[.so | .dll | .dylib | .sl | .dl | .a] does not exist in /Users/seth/Code/celeritas-temp/build/lib:/opt/spack/var/spack/environments/celeritas/.spack-env/view/lib::::.:/usr/local/lib:/usr/X11R6/lib:/usr/lib:/lib:/lib/x86_64-linux-gnu:/usr/local/lib64:/usr/lib64:/lib64:
Fatal in <TROOT::InitInterpreter>: cannot load symbol dlsym(RTLD_DEFAULT, CreateInterpreter): symbol not found
ninja: build stopped: subcommand failed.

@sethrj sethrj changed the title Use ROOT_LIBRARY_PATH environment variable for plugins, and cache… Use and cache ROOT_LIBRARY_PATH environment variable for plugins Dec 23, 2025
@jmcarcell
Copy link
Member

I'm not aware that ROOT requires ROOT_LIBRARY_PATH and we haven't found issues in the LCG or Key4hep stacks related to this with some of them using ROOT 6.38 or master. Can you find anything in ROOT related to that (release notes or PR)?
Using ROOT_LIBRARY_PATH (or even better, DD4HEP_PLUGIN_PATH not to pollute ROOT_LIBRARY_PATH) in the plugin system requires certainly a few more changes, like in https://gitlab.cern.ch/gaudi/Gaudi/-/merge_requests/1733.

@sethrj
Copy link
Author

sethrj commented Dec 29, 2025

@jmcarcell Thanks for the response. This is the first time I've gotten dd4hep to compile on macOS, so the issues may not be specific to the new version of ROOT but might be present in older ROOT versions as well.

I apologize for not making the intent of this change clearer. The error is that the CMake assumes the presence of certain environment variables in the original configure, and it assumes the environment won't change across rebuilds. (Best practice for cmake, and the way its configuration works, is to use cache variables that default to environment variables, thereby respecting the user configuration and persisting across runs.)

The cause of this issue is:

  1. listcomponents_dd4hep always requires the ROOT library path environment variable to run correctly (which may be a change to the new ROOT version, I'm not sure)
  2. CMake does not store $ENV across runs
  3. The original configure environment does not affect subsequent rebuilds/reconfigures.

Do you run your lcg/key4hep stacks on macos, and when you do, you do you always have (DY)LD_LIBRARY_PATH and ROOT_LIBRARY_PATH in the runtime environment? (This seems to be standard practice for HEP software stacks.) Do you ever configure, open a new terminal window or clear your environment, and try to rebuild? (This is the use case CMake is designed to allow.)

If you purge your environment of *_PATH variables, can you run listcomponents_dd4hep on a shared library without getting an error like the one I posted?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants