In inspectVM() the BlackBerry 10 Simulator installer v10.3.1 [1] resolves the /usr/bin/java symlink to /usr/libexec/eselect-java/run-java-tool.bash. Then it checks whether it found the Java VM binary, by checking the basename of the resolved name against "java". To confirm this, extract the first 10k lines of the installer and grep for: elif [ "$inspecteeName" = "java" ]; then Since Gentoo (app-eselect/eselect-java-0.1.0) names the file "run-java-tool.bash" instead of "java", the test breaks. Suggestion: Rename /usr/libexec/eselect-java/run-java-tool.bash to /usr/libexec/eselect-java/java, to make scripts, which resolve the symlink and check the resulting filename, happy. [1]: http://developer.blackberry.com/android/tools/
The same think hits us later, at: resolveLink "$actvm" actvm="$resolvedLink" I understand, that run-java-tool.bash needs the name of $0 to dispatch properly, which means that resolving the link will break it. Thus I currently have no suggestion how to fix this correctly.
This sounds pretty dumb. I don't know how resolving the symlink and checking the result is supposed to give any indication that it is a working VM or not. I haven't looked at it but as a workaround, you might be able to run it with PATH=$(java-config -O)/bin:${PATH}.
I don't think that will work, as it always resolves the symlink of "java", after searching all dirs in $PATH for it. But I found another workaround: Running the installer as "./the-installer.bin LAX_VM java" forces the JVM binary to be "java", which makes the symlink resolver fail, so it uses the name directly. Please note that starting it as "./the-installer.bin LAX_VM /usr/bin/java" will not work, as then it will still resolve the symlink of the forced binary.
old version 'app-eselect/eselect-java-0.1.0' is gone. closing.