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 (see section above ExternalPackages)
- order of library path searching: https://en.wikipedia.org/wiki/Rpath#GNU_ld.so. we think conda uses RPATH not RUNPATH.
Overview
Content Tools