Summary: | sun-jdk-1.5.0.06 has bad java.library.path | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andy Lutomirski <luto> |
Component: | [OLD] Development | Assignee: | Java team <java> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | bensagal, kurtg, rumi, tecnic5 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Andy Lutomirski
2006-03-08 21:12:03 UTC
*** Bug 96175 has been marked as a duplicate of this bug. *** Simple patch: --- /usr/bin/run-java-tool 2006-07-30 01:40:24.000000000 +0200 +++ run-java-tool 2006-08-15 14:10:09.000000000 +0200 @@ -1,5 +1,7 @@ #!/bin/bash +export LD_LIBRARY_PATH=/lib64:/usr/lib64:/lib32:/usr/lib32:/lib:/usr/lib + user_vm="${HOME}/.gentoo/java-config-2/current-user-vm" system_vm="/etc/java-config-2/current-system-vm" # Try GENTOO_VM applied to dev-java/java-config-2.0.26-r5 solves this for me: nelchael@nelchael tmp$ which java /home/nelchael/bin/java nelchael@nelchael tmp$ java pathtest /opt/sun-jdk-1.5.0.07/jre/lib/i386/client:/opt/sun-jdk-1.5.0.07/jre/lib/i386:/opt/sun-jdk-1.5.0.07/jre/../lib/i386:/lib64:/usr/lib64:/lib32:/usr/lib32:/lib:/usr/lib nelchael@nelchael tmp$ /usr/bin/java pathtest /opt/sun-jdk-1.5.0.07/jre/lib/i386/client:/opt/sun-jdk-1.5.0.07/jre/lib/i386:/opt/sun-jdk-1.5.0.07/jre/../lib/i386 nelchael@nelchael tmp$ Joshua: opionions about applying this patch for -r6 ? Probably not a good idea to totally overwrite LD_LIBRARY_PATH, since it could easily have stuff on it you need. Maybe prepend suggestted string to it? --- /usr/bin/run-java-tool 2006-07-30 01:40:24.000000000 +0200 +++ run-java-tool 2006-08-15 14:10:09.000000000 +0200 @@ -1,5 +1,7 @@ #!/bin/bash +export LD_LIBRARY_PATH=/lib64:/usr/lib64:/lib32:/usr/lib32:/lib:/usr/lib:${LIBRARY_PATH} + user_vm="${HOME}/.gentoo/java-config-2/current-user-vm" system_vm="/etc/java-config-2/current-system-vm" # Try GENTOO_VM Like this? (In reply to comment #4) This should be correct (you appended $LIBRARY_PATH forgetting the LD_) export LD_LIBRARY_PATH=/lib64:/usr/lib64:/lib32:/usr/lib32:/lib:/usr/lib:${LD_LIBRARY_PATH} Another way is to pass -Djava.library.path=foo to the java executable, but looks like it overrides the default, not additive, so LD_LIBRARY_PATH seems better. Note that eclipse-sdk now appends (after my pestering) -Djava.library.path for subclipse in eclipse.ini, which should probably be removed once the run-java-tools is fixed. What I did to make dev-java/tomcat-native to work with sun-jdk was the following: ln -s /usr/lib $JAVA_HOME/lib/i386 Maybe this could be a generic solution to the problem? Well, answering my own question: NO. I guess it's not amd64 proof in the first place and anyway... I should have slept the night before... ;-\ Hm, we have a LDPATH setting in vm's package.env that I think isn't used anywhere now (it's created from what java.library.path is in the VM, but we could easily add /usr/lib for sun-jdk-1.5). We also have LIBRARY_PATH in package.env of java packages (swt for example) that results in -Djava.library.path for gjl-based launchers (try output of 'gjl -p swt-3 -a'). So if we appended vm's package.env LDPATH (I think we should, because now we're overriding it), gjl-launcher based stuff would be ok. Wouldn't help manual execution or eclipse which has own launcher. So, would that be enough? Maybe eclipse's launcher could be also extended to take stuff from gjl into account? I just noticed this bug. I actually just patched the Eclipse loader to explicitly define -Djava.library.path=/usr/lib. Else Eclipse would not run on jdk-1.5. JDK-1.6 does not have the problem. (In reply to comment #8) > Hm, we have a LDPATH setting in vm's package.env that I think isn't used > anywhere now (it's created from what java.library.path is in the VM, but we > could easily add /usr/lib for sun-jdk-1.5). We also have LIBRARY_PATH in > package.env of java packages (swt for example) that results in > -Djava.library.path for gjl-based launchers (try output of 'gjl -p swt-3 -a'). > So if we appended vm's package.env LDPATH (I think we should, because now we're > overriding it), gjl-launcher based stuff would be ok. Wouldn't help manual > execution or eclipse which has own launcher. So, would that be enough? Maybe > eclipse's launcher could be also extended to take stuff from gjl into account? I'm still for patching run-java-tool as it's more global solution. sun-jdk:1.5 is not in the tree could this bug not be closed? |