Broken installation of Geant4 in GSI cvmfs image

[YanzhaoW]

Problem

The precompiled Geant4 Packages in cvmfs images have broken library linkages.

How to reproduce

1. Go to any GSI server with cvmfs mounted, e.g. dslustre01
2. Go to the FairSoft folder /cvmfs/fairsoft.gsi.de/debian11/fairsoft/jan24p5/lib and run the following command to check the library linkage:

ldd libG4materials.so

The result should look like:

As can be seen here, libraries like libG4global.so and libG4intercoms.so are not linked correctly.

What should be expected

Here is my own installation in a docker image:

where all dependent libraries are correctly linked (with empty LD_LIRBARY_PATH).

[fuhlig1]

Hi @YanzhaoW,

which system did you use to generate your example output?

I had a look in the Geant4 build system and there the RPATH is handled only for macosx explicitly. For a Linux system you do not add any RPATH information, so I wonder how you have the proper RPATH information added.

Ciao

Florian

[YanzhaoW]

Hi @fuhlig1

It's Fedora 42. I made this from an apptainer container running in one of GSI lustre.hpc servers. I didn't change anything in the installation of Geant4.

The docker image is yanzhaowang/r3bdev:fedora-latest. You can find it in the dockerhub.

The dockerfile to generate it can be found here: https://github.com/YanzhaoW/Dockerfiles/blob/master/r3bdev/fedora-latest/Dockerfile

[fuhlig1]

Hi @YanzhaoW,

thanks. I will check with my Fedora 42 image.

Could you please add the output of

readelf -d libG4materials.so

[YanzhaoW]

sure.

  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libG4intercoms.so]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libG4global.so]
 0x0000000000000001 (NEEDED)             Shared library: [libCLHEP-2.4.7.1.so]
 0x0000000000000001 (NEEDED)             Shared library: [libG4ptl.so.3]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libG4materials.so]
 0x000000000000000c (INIT)               0x224
 0x000000000000000d (FINI)               0x65084
 0x0000000000000019 (INIT_ARRAY)         0xbf648
 0x000000000000001b (INIT_ARRAYSZ)       24 (bytes)
 0x000000000000001a (FINI_ARRAY)         0xbf660
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x66000
 0x0000000000000005 (STRTAB)             0x6bf10
 0x0000000000000006 (SYMTAB)             0x67410
 0x000000000000000a (STRSZ)              38824 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0xbffe8
 0x0000000000000002 (PLTRELSZ)           9744 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x771e8
 0x0000000000000007 (RELA)               0x75e68
 0x0000000000000008 (RELASZ)             4992 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x75cf8
 0x000000006fffffff (VERNEEDNUM)         4
 0x000000006ffffff0 (VERSYM)             0x756b8
 0x000000006ffffff9 (RELACOUNT)          26
 0x0000000000000000 (NULL)               0x0

[fuhlig1]

Hi @YanzhaoW,

thanks for the fast response. I will have to check with your image. When checking my image I get the libraries without RPATH information

ldd libG4materials.so 
	linux-vdso.so.1 (0x00007fffd1ff2000)
	libG4intercoms.so => not found
	libz.so.1 => /lib64/libz.so.1 (0x00007f8abe071000)
	libG4global.so => not found
	libCLHEP-2.4.7.1.so => not found
	libG4ptl.so.3 => not found
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8abddf8000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f8abdd0a000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8abdcde000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f8abdaed000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8abe17b000)

This is what I expect from the Geant4 build.

Concerning the information from the output of the readelf command it is what I have expected. There is no RPATH information stored in the library file. If you compare this with one of the ROOT libraries you miss the RUNPATH information which is needed such that the libraries can be properly found.

Tag        Type                         Name/Value
0x0000000000000001 (NEEDED)             Shared library: [libThread.so.6.36]
0x0000000000000001 (NEEDED)             Shared library: [libCore.so.6.36]
0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
0x000000000000000e (SONAME)             Library soname: [libRIO.so.6.36]
0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/]
0x000000000000000c (INIT)               0x2cc
0x000000000000000d (FINI)               0x31b2a8
0x0000000000000019 (INIT_ARRAY)         0x4a8e38
0x000000000000001b (INIT_ARRAYSZ)       288 (bytes)
0x000000000000001a (FINI_ARRAY)         0x4a8f58
0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
0x0000000000000004 (HASH)               0x31c000
0x000000006ffffef5 (GNU_HASH)           0x326860
0x0000000000000005 (STRTAB)             0x358670
0x0000000000000006 (SYMTAB)             0x3314c0
0x000000000000000a (STRSZ)              540426 (bytes)
0x000000000000000b (SYMENT)             24 (bytes)
0x0000000000000003 (PLTGOT)             0x4b8fe8
0x0000000000000002 (PLTRELSZ)           31992 (bytes)
0x0000000000000014 (PLTREL)             RELA
0x0000000000000017 (JMPREL)             0x40f160
0x0000000000000007 (RELA)               0x3dfb50
0x0000000000000008 (RELASZ)             194064 (bytes)
0x0000000000000009 (RELAENT)            24 (bytes)
0x000000006ffffffe (VERNEED)            0x3df9a0
0x000000006fffffff (VERNEEDNUM)         5
0x000000006ffffff0 (VERSYM)             0x3dc57a
0x000000006ffffff9 (RELACOUNT)          88
0x0000000000000000 (NULL)               0x0

Could it be that you have added the directory to the defaul search path of the dynamic linker?

[fuhlig1]

Hi @YanzhaoW,

can I get your Docker image from somewhere?

[YanzhaoW]

Oh, sure. I thought you could just pull it via the name:

docker pull yanzhaowang/r3bdev:fedora-latest

The image can be found here: https://hub.docker.com/repository/docker/yanzhaowang/r3bdev/general

[YanzhaoW]

@fuhlig1

Sorry, I just found the image I provided has the same problem. I will try to find the image that I used in the original post.

[fuhlig1]

@fuhlig1

Sorry, I just found the image I provided has the same problem. I will try to find the image that I used in the original post.

Okay. That is what I also found out.

[YanzhaoW]

Have you tried to install Geant4 independently and see whether the RPATH is embedded in the libraries?

[fuhlig1]

I did not try this, but I doubt that it will work. Looking at the Geant4 build system (CMake) there is no RPATH handling for Linux at all, so I don't see how the info can be added to the library.

[YanzhaoW]

I see. I will share my progress here if I found any solution.

[YanzhaoW]

Hi, @fuhlig1

I have installed the Geant4 independently and the problem still exists. So I created an issue in Geant4 forum. You can check it here: https://geant4-forum.web.cern.ch/t/geant4-shared-libraries-dont-have-rpath-embedded/14507

[fuhlig1]

Hi @YanzhaoW,

thanks for creating the issue with Geant4 since it would be nice if they would fix the issue on their side. Anyway we found a way to fix the RPATH information on our side. The fix will be included in the next release.

[YanzhaoW]

@fuhlig1

Ok, it seems that they don't want to enable it by default because there could be some hypothetical people who will complain about it, even though embedding the runpath doesn't seem to have any drawbacks and most of libraries have this by default.

If I'm correct, your solution is to setup the CMAKE_INSTALL_RPATH from the cli, like:

cmake -DCMAKE_INSTALL_RPATH="\$ORIGIN" <otherargs>

As I mentioned there, this fixes the linkage from library folder, but not the bin folder. And we still have quite lots of Geant4 binaries there unlinked. Most of them are built from examples and kinda useless. Could you disable the example building from Geant4?