New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolve symlinked java command to find home #6639
Conversation
On many Linux systems, the installed `java` command will live in /usr/bin and point via a chain of symlinks to the actual JDK home installation under (for example) /usr/lib/jvm/<java-home>. This symlinking interferes with our detecting where Java actually lives, leading to issues like jruby#6637. This patch uses existing logic for resolving a trail of symlinks, allowing us to dig down to the actual binary `java` and from there determine its JAVA_HOME. Fixes jruby#6637. See also jruby/jruby-launcher#34 which will need a similar fix in C.
These should be visible from within the launched JRuby process.
First attempt at a test failed, indicating that the JDK installs on Ubuntu also symlink |
There is no standard way in POSIX shell to determine the target of a symlink, so we are forced to use readlink.
export will hide the failure of the command on the RHS used as the value, so export only the variable names.
Additional improvements thanks to @mrnoname1000:
|
From de400b6:
|
I decided I am not comfortable with this change, since it would mean launching a subprocess JRuby with a different home or Java would require *clearing* these variables rather than just pointing at a new jruby or java executable. See #6639.
This PR fixes #6637 by fully resolving any symlinks between the
java
command (found from$JAVACMD
orjava
in PATH) before using that command's path to determine$JAVA_HOME
.The issue affects systems without
$JAVA_HOME
set, but that have ajava
command in PATH that resolves to a$JAVA_HOME/bin/java
through a series of symlinks (e.g. CentOS).This PR also exports
JRUBY_HOME
,JAVACMD
, andJAVA_HOME
so they will be seen by the JRuby process and subprocesses, avoiding recalculating this home or accidentally using a different JDK for additional JRuby launches.I have added a test case for the symlink situation.