Celeritas-DD4hep Build Issues in eic-shell CUDA container

[rahmans1]

When trying to build celeritas-dd4hep integration inside eic-shell cuda container either with VecGeom on or off, i get the following error:

[ 95%] Built target DDcelerRunAction
[ 95%] Generating libDDcelerRunAction.components
/opt/local/bin/listcomponents_dd4hep: symbol lookup error: /opt/software/linux-x86_64_v2/vecgeom-1.2.11-lgw54otbmdlhbrpejyvrdowliop2s7ws/lib/libvecgeom.so: undefined symbol: __cudaRegisterLinkedBinary_cc0e9c90_13_BVHManager_cu_d7829d8f_358471
gmake[2]: *** [src/ddceler/CMakeFiles/Components_DDcelerRunAction.dir/build.make:73: src/ddceler/libDDcelerRunAction.components] Error 127
gmake[2]: *** Deleting file 'src/ddceler/libDDcelerRunAction.components'
gmake[1]: *** [CMakeFiles/Makefile2:1572: src/ddceler/CMakeFiles/Components_DDcelerRunAction.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....

I was able to override this behavior with a preload but now i get a new error

LD_PRELOAD=$(spack location -i vecgeom)/lib/libvecgeom_final.so:$PWD/build/lib/libcorecel_final.so:$PWD/build/lib/libceleritas_final.so:$PWD/build/lib/libgeocel_final.so:$PWD/build/lib/libaccel_final.so cmake --build build -j 8
cmake: symbol lookup error: /home/srahman1/celeritas-dd4hep/celeritas-cuda/build/lib/libaccel_final.so: undefined symbol: __fatbinwrap_4b0419a7_25_AlongStepNeutralAction_cu_e6c2c0f1_393202

[sethrj]

@pcanal could you help with this RDC linking issue?

[pcanal]

The library needing to be loaded is libvecgeom_final rather than plain libvecgeom which is not complete.

[rahmans1]

The library needing to be loaded is libvecgeom_final rather than plain libvecgeom which is not complete.

@pcanal Yes. Once i preloaded libvecgeom_final, i didn't see the vecgeom related error anymore but i saw a new error as shown in the second block.

[pcanal]

Right. You can/need to only load one single _final library (they contains duplicate but conflicting (weak) symbols and other weird nvlink cruft). It has to be the most derived one, i.e. the library that depends/uses all the others.
In the case above you have to load only libaccel_final as it should already contains the links for the dependent libraries (libvecgeom, etc.).

[sethrj]

@pcanal If different executables launched during the cmake process require different (conflicting!) environment variables, we might be in trouble. Is that the case?

[pcanal]

In this case, I think it is okay to always request a superset:

LD_PRELOAD=$PWD/build/lib/libaccel_final.so cmake --build build -j 8