This post is especially important for those Unix users who install PLplot dependencies (such as libLASi) in non-standard locations and who use the traditional build of our installed examples rather than the CMake-based build of those examples.
DT_RPATH and its more modern variant DT_RUNPATH are two ways on Unix systems to inform the run-time loader of non-standard locations of shared libraries that are needed by applications. Therefore, the details of how our build system configures use of the INSTALL_RPATH target property (which controls DT_RPATH on old Unix systems such as Debian Jessie and DT_RUNPATH on more modern Unix systems such as Debian Testing) become important for the traditional build of installed examples if any external library (e.g., libLASi) needed by any PLplot component is installed in a non-standard location. (Note that CMake-based builds automatically take care of all rpath concerns so our CMake-based core build and CMake-based build of the installed examples automatically work fine regardless of where our external libraries are installed or the INSTALL_RPATH target property set for them.) Our INSTALL_RPATH configuration worked fine for our traditional builds of installed examples on DT_RPATH platforms such as Debian Jessie and was extensively tested in that era with epa_built external libraries that were installed in non-standard locations. However, that configuration did not work correctly for DT_RUNPATH platforms such as Debian Testing since it was not always consistent the following additional constraint on the use of DT_RUNPATH that has been taken from <https://refspecs.linuxfoundation.org/elf/gabi4+/ch5.dynamic.html>: "The set of directories specified by a given DT_RUNPATH entry is used to find only the immediate dependencies of the executable or shared object containing the DT_RUNPATH entry. That is, it is used only for those dependencies contained in the DT_NEEDED entries of the dynamic structure containing the DT_RUNPATH entry, itself. One object's DT_RUNPATH entry does not affect the search for any other object's dependencies." As a result PLplot's use of the new libLASi release (which necessarily had to be built locally and with a non-standard install prefix) failed for our traditional build. To address this issue I have completely rewritten our rpath configuration logic (see commits plplot-5.14.0-24-ge418008c8 through plplot-5.14.0-29-g3b140b22f) to (i) be consistent with the above additional DT_RUNPATH constraint, and (ii) have that configuration done in a standardized way for all our installed targets (executables, dll's (modules) generated by swig, ordinary dll's, shared libraries and static libraries). The result of this work is a substantial reduction in the number of lines of CMake logic in our build system (since virtually all of the INSTALL_RPATH logic is now taken care of in the configure_executable_build and configure_library_build functions) and the install of the new libLASi release is found and used for traditional builds without issues. Note that this new logic always uses transitive INSTALL_RPATH logic for the static build case and by default uses non-transitive INSTALL_RPATH logic for the shared library case (regardless of whether the device drivers are dynamic or nondynamic). And that default for the shared library case works well for Debian Testing. But if there are still some Unix platforms out there that only work for transitive INSTALL_RPATH logic for the shared library case, the user can choose that logic by setting the -DNON_TRANSITIVE_RPATH=OFF cmake option. And as always if the user (typicall a binary package maintainer) specifies -DUSE_RPATH=OFF, the INSTALL_RPATH target property (transitive or otherwise) will not be set at all for installed targets with the result that DT_RPATH (old Unix systems) and DT_RUNPATH (modern Unix systems) will not be set for those targets. In sum, my recent comprehensive tests support the idea that our INSTALL_RPATH configuration should "just work" now for the combination of the traditional build of our installed examples and non-standard installed locations of PLplot dependencies. But if the run-time loader errors out by saying it cannot find a library, the first thing you should try is -DUSE_RPATH=ON (if you were not using that default already) and the second thing you should try if this trouble occurs for the shared build case is -DNON_TRANSITIVE_RPATH=OFF. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
