I have blackdown-jdk-1.4.2.03 and sun-jdk-1.5.0.06 installed, with blackdown set as the system VM and all java ebuilds built with blackdown. blackdown's java.library.path is fine. sun's is missing /lib and /usr/lib. $ cat pathtest.java public class pathtest { public static void main(String[] args) throws Exception { System.out.println(System.getProperty("java.library.path")); } } $ javac pathtest.java $ /opt/blackdown-jdk-1.4.2.03/bin/java pathtest /usr/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/server:/usr/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64:/usr/opt/blackdown-jdk-1.4.2.03/jre/../lib/amd64:/usr/lib64:/lib64 $ /opt/sun-jdk-1.5.0.06/bin/java pathtest /usr/opt/sun-jdk-1.5.0.06/jre/lib/amd64/server:/usr/opt/sun-jdk-1.5.0.06/jre/lib/amd64:/usr/opt/sun-jdk-1.5.0.06/jre/../lib/amd64 $ #Note absence of /lib and /usr/lib above. $ LD_LIBRARY_PATH=/lib:/usr/lib /opt/sun-jdk-1.5.0.06/bin/java pathtest /usr/opt/sun-jdk-1.5.0.06/jre/lib/amd64/server:/usr/opt/sun-jdk-1.5.0.06/jre/lib/amd64:/usr/opt/sun-jdk-1.5.0.06/jre/../lib/amd64:/lib:/usr/lib $ #Hmm... It's back now. I noticed this because subversion's java bindings were failing to load under java 1.5. Setting LD_LIBRARY_PATH fixed it. They work find on blackdown. The error was: $ java -cp /usr/lib/svn-javahl/svn-javahl.jar:. SubversionDemo 2>&1 Exception in thread "main" java.lang.UnsatisfiedLinkError: no svnjavahl in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:992) at org.tigris.subversion.javahl.NativeResources.loadNativeLibrary(NativeResources.java:78) I get the same results with a completely empty environment (env -i). # java-config -L [sun-jdk-1.5.0.06] "Sun JDK 1.5.0.06" (/etc/env.d/java/20sun-jdk-1.5.0.06) [blackdown-jdk-1.4.2.03] "Blackdown JDK 1.4.2.03" (/etc/env.d/java/20blackdown-jdk-1.4.2.03) * Portage 2.0.54 (default-linux/amd64/2006.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15-gentoo-r3 x86_64) ================================================================= System uname: 2.6.15-gentoo-r3 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/boot/grub:/usr/lib/perl5/vendor_perl/5.8.4/Netcomics/etc /etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/ http://gentoo.mirrors.pair.com/ http://gentoo.osuosl.org" MAKEOPTS="-j2" PKGDIR="/var/tmp/safe/portage-pkg" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aalib acl alsa apache2 audiofile avi bash-completion berkdb bitmap-fonts boo bzip2 cairo cdr crypt cups curl dvd eds emboss encode esd ethereal exif expat f77 fam ffmpeg flac foomaticdb fortran gcj gd gdbm gif glitz glut gmp gnome gpm gstreamer gtk gtk2 gtkhtml idn imagemagick imlib ipv6 ithreads java jpeg junit kde kerberos krb4 lcms libedit libwww lzw lzw-tiff mad mhash mikmod mng mono mozilla mozsvg mp3 mpeg mysql ncurses network nls nptl nsplugin ogg opengl pam pcre pdflib perl php png postgres python qt quicktime readline samba sasl sdl slang snmp spell sqlite ssl svg tcltk tcpd tetex threads tiff truetype truetype-fonts type1-fonts udev usb userlocales v4l2 vhosts vorbis xine xml xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
*** 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?
