You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hashlink's rpath settings have been a mess for a while, which has caused various hdll loading issues in the past.
It would be good to finally solve this issue properly so that all use cases can be accommodated for without problems, perhaps by an option switching between different rpath settings.
So, here are some hashlink installation/distribution methods I can think of that it would be worth supporting:
Local distribution with another app
This is the method of distributing an app by packaging hashlink together with the hdlls in a single directory. This requires the hashink binary to be able to load hdlls from the distributed directory, so RPATH must contain ORIGIN.
System hashlink install
This is when hashlink is installed into a system directory, for example /usr/ or /usr/local/. It will have to load hdlls from the install prefix library directory, i.e. /usr/lib or /usr/local/lib, as well as the current working directory, in order to load extra user-made hdlls. Therefore, the RPATH must contain /usr/local/lib and CWD.
Relocatable hashlink install
This is useful for when someone wants to download the hashlink nightly package, unzip it, add it to PATH and expects it to work as is. This also requires loading from the distributed directory, aka ORIGIN, as well as the current working directory to download extra user-made hdlls. Therefore, the RPATH must contain ORIGIN and CWD.
Perhaps the makefile can provide an option for switching between these 3 configurations. Not including the unnecessary RPATH entries removes the security risks of loading binaries from potentially untrusted locations unless specifically required. As Nicolas mentioned in a previous thread:
it might load untrusted binaries with privileges without notice.
Apart from this which would solve the issues on Linux, we also need to add RPATH settings for Darwin. That has slightly different RPATH conventions so it would require investigating those as well as the various package managers on MacOS (mainly Homebrew and Nix) and making a decision based on that.
The text was updated successfully, but these errors were encountered:
Hashlink's rpath settings have been a mess for a while, which has caused various hdll loading issues in the past.
It would be good to finally solve this issue properly so that all use cases can be accommodated for without problems, perhaps by an option switching between different rpath settings.
So, here are some hashlink installation/distribution methods I can think of that it would be worth supporting:
Local distribution with another app
This is the method of distributing an app by packaging hashlink together with the hdlls in a single directory. This requires the hashink binary to be able to load hdlls from the distributed directory, so RPATH must contain
ORIGIN
.System hashlink install
This is when hashlink is installed into a system directory, for example
/usr/
or/usr/local/
. It will have to load hdlls from the install prefix library directory, i.e./usr/lib
or/usr/local/lib
, as well as the current working directory, in order to load extra user-made hdlls. Therefore, the RPATH must contain/usr/local/lib
andCWD
.Relocatable hashlink install
This is useful for when someone wants to download the hashlink nightly package, unzip it, add it to PATH and expects it to work as is. This also requires loading from the distributed directory, aka
ORIGIN
, as well as the current working directory to download extra user-made hdlls. Therefore, the RPATH must containORIGIN
andCWD
.Perhaps the makefile can provide an option for switching between these 3 configurations. Not including the unnecessary RPATH entries removes the security risks of loading binaries from potentially untrusted locations unless specifically required. As Nicolas mentioned in a previous thread:
Apart from this which would solve the issues on Linux, we also need to add RPATH settings for Darwin. That has slightly different RPATH conventions so it would require investigating those as well as the various package managers on MacOS (mainly Homebrew and Nix) and making a decision based on that.
The text was updated successfully, but these errors were encountered: