Found using oracle-jdk-bin-1.7.0.45.ebuild: ldd can't find shared java libraries, because the current java is not set up in LD_LIBRARY_PATH: ldd /opt/oracle-jre-bin-1.7.0.45/lib/amd64/libsunec.so libjvm.so => not found libjava.so => not found set_java_env in java-vm-2.eclass creates an env file in /usr/share/java-config-2/vm/oracle-jdk-bin-1.7. java-config maintains a symlink /etc/java-config-2/current-system-vm to the vm's home directory. However, neither touches env.d so the linker can't find the current java libs by itself. This fixes the problem. Hopefully it can make it into java-config. # make /etc/env.d/99java for current java's environment rm -f /etc/env.d/99java ( ENV="$(cat /usr/share/java-config-2/vm/$(java-config -f))" # careful to escape quotes and backslashes ENV_ESC="$(echo "$ENV" | sed -e 's/\\/\\\\/g' -e 's/\"/\\\"/g')"; # set variables then echo $ENV to expand them all eval "$ENV" eval "echo \"$ENV_ESC\"" ) | tee /etc/env.d/99java env-update && source /etc/profile (It'd be nicer just to copy the java config file directly into env.d, but the config file contains variable references that env-update doesn't expand)
gmturner pointed out a shorter way to make the java environment: java-config -P $(java-config -f) > /etc/env.d/99java
(In reply to Noel Burton-Krahn from comment #0) > Found using oracle-jdk-bin-1.7.0.45.ebuild: > > ldd can't find shared java libraries, because the current java is not set up > in LD_LIBRARY_PATH: > > ldd /opt/oracle-jre-bin-1.7.0.45/lib/amd64/libsunec.so > libjvm.so => not found > libjava.so => not found Well, those two libraries are supposed to be loaded by the jre exclusively. The vm loader does find them. So everything is still fine up to this point. > > set_java_env in java-vm-2.eclass creates an env file in > /usr/share/java-config-2/vm/oracle-jdk-bin-1.7. java-config maintains > a symlink /etc/java-config-2/current-system-vm to the vm's home > directory. However, neither touches env.d so the linker can't find the > current java libs by itself. set_java_env would better be named java-vm_do_java_config_file or similar. The intention and only role of this function is to install the equivalent of a .pc file for use with java-config. Once upon a time java-config was like gcc-config used to select a vm. Later emerged eselect and the eselect java-vm module took that role. With generation 2 java-config mostly became what pkgconfig is for native code. Conceptually /etc/java-config-2/current-system-vm belongs to baselayout-java and the primary tool to maintain the symlink is in eselect-java. A decade of compatibility code doesn't help to see what's going on ;) > This fixes the problem. Hopefully it can make it into java-config. How do you intend to support user-vms? How does this work with dynamic vm switching in eclasses and gjl? There are many pitfalls down that road. I'd suggest you look up java.library.path and look into gjl, the java-pkg_dolauncher function should be a sufficient recipe for how to use the latter. Closing as invalid as it's nowhere close to a ready proposal (both abstract problem description and implementation) and no actual breakage was shown.
