| Summary: | wrong installation path on Debian based distros | ||
|---|---|---|---|
| Product: | Environments | Reporter: | Stephan Lachnit <stephan.lachnit> |
| Component: | g4py | Assignee: | Ben Morgan <Ben.Morgan> |
| Status: | REOPENED FIXED | ||
| Severity: | major | ||
| Priority: | P4 | ||
| Version: | 10.6 | ||
| Hardware: | All | ||
| OS: | Linux | ||
I think the temporary workaround for the upcoming release (unless I can find a recommendation) will be to make `CMAKE_INSTALL_PYTHONDIR` configurable. On the `RPATH` issue, that's there to help novice users, but I'll look at documenting the CMake options to disable this. In any case, packaging systems should have the option to strip RPATH at packaging time? > On the `RPATH` issue, that's there to help novice users, but I'll look at documenting the CMake options to disable this. In any case, packaging systems should have the option to strip RPATH at packaging time?
I currently strip the RPATH setting from the libraries, so it's not that much of an issue, I am just wondering why it is enabled by default. I am not aware of a case where the RPATH setting would help, but maybe I'm just missing some edge case here.
The `RPATH` setting is purely so that novice users (or those who can't modify `ld.so.conf`) who may build/install Geant4 themselves from source don't need to set `(DY)LD_LIBRARY_PATH` to point to the Geant4 libraries that the Python modules link to. I don't pretend that's a good/best way to do things, but a covers a very wide range of users. That said, if there are official Debian packages available, we're happy to advertise these as an option for installation. A fix making `CMAKE_INSTALL_PYTHONDIR` user configurable is now merged upstream and will be in December's release. I'll continue to see if CMake can support better auto-detection. For now, the RPATHs in the modules are retained, but can easily be stripped at install time by packaging tools or through the build with the `CMAKE_SKIP_INSTALL_RPATH` variable. Thanks! Seems like the variable doens't work as intended for me. If I set CMAKE_INSTALL_PYTHONDIR=lib/python3/dist-packages, it won't go to $DESTDIR$CMAKE_INSTALL_PREFIX$CMAKE_INSTALL_PYTHONDIR as expected, but to $DESTDIR$DESTDIR$CMAKE_INSTALL_PREFIX$CMAKE_INSTALL_PYTHONDIR. I.e. if I build to /tmp/destdir, it will go to /tmp/destdir/tmp/destdir/usr/lib/python3/dist-packages. |
When installing the Python module using GEANT4_USE_PYTHON=ON on Debian based distros, this will result in a wrong installation path. Currently, CMAKE_INSTALL_PYTHONDIR is set to ${CMAKE_INSTALL_LIBDIR}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages. On FHS 3.0 systems which don't respect Multi-Arch, this will be /usr/lib/python3.X/site-packages, which is indeed correct, however Debian based system have a suffix, which means CMAKE_INSTALL_LIBDIR is not /usr/lib but (for example) /usr/lib/x86_64-linux-gnu. I'm not fluent enough in cmake to be aware of any automatic workaround, but it would already be helpful if CMAKE_INSTALL_PYTHONDIR could be set by the user. Also, the compiled libraries of the Python module have an RPATH set, and I'm entirely sure why. Usually this is discouraged in favor of dynamic link path resolving. Also, the RPATH makes it impossible to relocate the installed libraries, which especially is a problem considering the Multi-Arch problems mentioned above.