Don't use LD_LIBRARY_PATH

[glennmorris]

Hi,

On CentOS, the init scripts etc/login and etc/profile set LD_LIBRARY_PATH, so that various binaries (and libraries) can find their dependencies. This is a problem, because Starlink includes several libraries that can already be present as system libraries, eg libtcl8.5.so. The use of LD_LIBRARY_PATH means that the Starlink versions are found before the system versions, which can break non-Starlink applications.

For example, after setting up Starlink 2017, /usr/bin/modulecmd no longer works on my RHEL7 system due to finding the Starlink libtcl rather than the system version.

This isn't a new issue, eg
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=STARLINK;d68387aa.1303

and you have a note about it on
http://starlink.eao.hawaii.edu/starlink/2017ADownload

Your issue #1 is about fixing this for OS X. I think it would be great to also fix it for Linux.

I see that you set RPATH for Starlink binaries so that builds using the standard /star-2017A installation location (aside: maybe something like /opt/starlink would be better these days?) don't need to rely on LD_LIBRARY_PATH. Eg:

readelf -d bin/xmake | grep RPATH -> /star-2017A/lib

RPATH can also contain relative paths, which means that this can be fixed for all installations, whether or not they use the /star-2017A prefix. The syntax for bin/xmake would be RPATH=$ORIGIN/../lib.

This approach is already used by the third-party java/ directory. Eg

readelf -d java/bin/java | grep RPATH -> $ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli

The patchelf utility (https://nixos.org/patchelf.html) can be used to correct RPATH after the fact.
So if it's too difficult to generate correct RPATHs during the build, a script can be used to fix them up after the fact, like macos_postbuild_library_fixup.sh does for OS X. Then there would be no need to set LD_LIBRARY_PATH.

Thanks for looking after Starlink!