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.
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:
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
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.
Hi,
On CentOS, the init scripts
etc/loginandetc/profileset 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/modulecmdno 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-2017Ainstallation location (aside: maybe something like/opt/starlinkwould be better these days?) don't need to rely on LD_LIBRARY_PATH. Eg:readelf -d bin/xmake | grep RPATH->/star-2017A/libRPATH can also contain relative paths, which means that this can be fixed for all installations, whether or not they use the
/star-2017Aprefix. The syntax for bin/xmake would beRPATH=$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/jliThe
patchelfutility (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, likemacos_postbuild_library_fixup.shdoes for OS X. Then there would be no need to set LD_LIBRARY_PATH.Thanks for looking after Starlink!