[Plplot-devel] A complete rewrite of the build system INSTALL_RPATH configuration logic has now been finished

[Alan W. I. <Ala...@gm...>]

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
__________________________