Page History

...

• conda has it's own "sysroot" with /lib and /include
• these can conflict with OS default sys root, but conda avoids that by using RPATH in the executables
• setting LD_LIBRARY_PATH can couple these two incompatible worlds: we saw this with conda's libattr.so.1 (dependency of Qt) breaking "ls"
• but psana1 test releases need to load alternate libraries (currently we use LD_LIBRARY_PATH)
• proposed solution: use LD_PRELOAD which can be set on a library-by-library basis for psana1 test releases
• when we build a binary in a development release we don't use RPATH, so that's why we had been using LD_LIBRARY_PATH (we think)
• preliminary test-release possible proposal:
  • eliminate use of LD_LIBRARY_PATH
  • use RPATH for building development binaries
    • can be set to ONLY point to conda's sysroot (this would be just like conda)
    • could also set to first the test-release library path then conda, but it might simpler to just use LD_PRELOAD everywhere
  • use LD_PRELOAD (which can be set on per-library basis) to "jam" development .so files to run
  • to test this: checkout "psana" (builds some binaries) and "Detector" (this creates a .so)
• modified proposal:
  • valmar and cpo found that binaries and libraries have $ORIGIN/../lib and $ORIGIN/../lib/python in the RPATH.  feels like this should work without LD_PRELOAD and LD_LIBRARY_PATH.  We'll try that and see what failure modes emerge.
  • conclusion so far (Dec. 2022) is that this seems to be working if we also checkout the right external packages
• order of library path searching:  https://en.wikipedia.org/wiki/Rpath#GNU_ld.so.  we think conda uses RPATH not RUNPATH.