http://bugzilla.opensuse.org/show_bug.cgi?id=1198352 http://bugzilla.opensuse.org/show_bug.cgi?id=1198352#c1 Jean-Noel Grad <jgrad@icp.uni-stuttgart.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jgrad@icp.uni-stuttgart.de --- Comment #1 from Jean-Noel Grad <jgrad@icp.uni-stuttgart.de> --- Created attachment 858054 --> http://bugzilla.opensuse.org/attachment.cgi?id=858054&action=edit Draft patch for 4.0.2 release of ESPResSo If I understand the documentation correctly, one cannot use a custom Rpath with OpenSUSE (https://en.opensuse.org/openSUSE:Packaging_checks#Beware_of_Rpath). In this package, we set the Rpath in the shared objects to avoid having to modify environment variables at runtime, such as LD_LIBRARY_PATH on Linux distributions. This is the easiest approach for end users, although I can see how this might be an issue when packaging the software. To make the package pass the brp-rpath check, we could remove the Rpath from the CMake logic and instead configure LD_LIBRARY_PATH in the pypresso/ipypresso wrapper scripts to include the espressomd python folder. I quickly tried it on the 4.2.0-dev version of ESPResSo and it seems to work. In the attached file, I attempted to backport the patch for 4.0.2. I'm quite busy this week working on the 4.2.0 release. If this is not urgent, I can have a closer look at the end of April and try running an OSC pipeline with the patch. If we go with this solution, we might have issues with library name collision at some point. ESPResSo can be built with external libraries such as ScaFaCoS, Stokesian Dynamics and waLBerla, which all provide their own .so files. If by accident one of the Cython modules in ESPResSo has the same name as one of these external shared objects, we might not be able to load ESPResSo in Python anymore. -- You are receiving this mail because: You are on the CC list for the bug.