Both Blackdown and Sun JDKs ship with libjava.so, and accompanying libraries. Unfortunately, libjava.so depends on libverify.so, which it cannot find. Output from 'ldd libjava.so' (Sun JDK 1.4.1-03): libjvm.so => not found libverify.so => not found libnsl.so.1 => /lib/libnsl.so.1 (0x40029000) libdl.so.2 => /lib/libdl.so.2 (0x4003e000) libc.so.6 => /lib/libc.so.6 (0x40041000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) and from Blackdown: libjvm.so => /opt/sun-jdk-1.4.1.03/jre/lib/i386/client/libjvm.so (0x40027000) libverify.so => not found libnsl.so.1 => /lib/libnsl.so.1 (0x404cc000) libdl.so.2 => /lib/libdl.so.2 (0x404e1000) libc.so.6 => /lib/libc.so.6 (0x404e4000) libgcc_s.so.1 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgcc_s.so.1 (0x40614000) libm.so.6 => /lib/libm.so.6 (0x4061c000) libpthread.so.0 => /lib/libpthread.so.0 (0x4063f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libverify.so lives inside the same directory as libjava.so. For the life of me, I can't figure out why libjava.so can't find libverify.so. This problem is preventing Java support in the PHP ebuilds. Here's the PHP error that results: Fatal error: Unable to load Java Library /opt/blackdown-jdk-1.4.1/jre/lib/i386/libjava.so, error: libverify.so: cannot open shared object file: No such file or directory in /usr/lib/php/extensions/no-debug-non-zts-20020429/java-test.php on line 2 I can't figure out whether ld.so is broken, or the Java packages :( As an aside, LDPATH in /etc/env.d/20java should be set to LDPATH=/opt/sun-jdk-1.4.1.03/jre/lib/i386 at the moment, it's being set to LDPATH=/opt/sun-jdk-1.4.1.03/jre/lib Best regards, Stu -- Reproducible: Always Steps to Reproduce: 1. Install JDK (Sun or Blackdown, it doesn't matter) 2. cd $JAVA_HOME/jre/lib/i386 3. ldd libjava.so Actual Results: libverify.so cannot be found Expected Results: libverify.so should be resolved correctly.
:( libjava.so loads just fine under PHP CLI - but not under mod_php. Hrm. Still doesn't explain how libverify.so is not found tho. Stu
mod_php installs fine for me, but i verify the libverify error not found (woh..) absinthe, this is right up your alley i do believe.
I cannot reproduce: phugeet root # locate libverify.so /opt/blackdown-jdk-1.3.1/jre/lib/i386/libverify.so /opt/blackdown-jdk-1.4.1/jre/lib/i386/libverify.so /opt/sun-jdk-1.4.2.02/jre/lib/i386/libverify.so phugeet root # qpkg -f /opt/blackdown-jdk-1.4.1/jre/lib/i386/libverify.so dev-java/blackdown-jdk * phugeet root # Please reopen if this is still relevant.
Whoa, sorry, I'll open my eyes next time!
I fixed this by conf.d/apache2 +JAVA_LIBRARY_PATH=$(java-config -O)/jre/lib/i386/ init.d/apache2 - env -i PATH=$PATH /sbin/start-stop-daemon --quiet \ + env -i PATH=$PATH LD_LIBRARY_PATH=${JAVA_LIBRARY_PATH} /sbin/start-stop-daemon --quiet \ not the cleanest solution, but seems to be the only one to me
if you want to add this the apache ebuild it would be nice, if not wontfix it after lots of testing & googling, i believe my previous comment is the only way to solve this
Well, as of sun-jdk-1.4.2_07, this problem still exists. With jre/lib/i386 and jre/lib/i386/server known to ld.so -- same symptoms. libverify.so not found, the file is there, and "ldd .../libverify.so" shows no errors :(((( AFAIK, this prevents a php-cgi build with java support and the Sun JVM.
I investigated a bit and dug out this: it seems that ld.so is unable to find libverify.so in one particular directory, that is /opt/sun-jdk-1.4.2.07/jre/lib/i386. ldconfig doesn't help, but moving/copying libverify.so to some other dir helps allright!!! I made a copy of libverify.so in jre/lib/i386/server (which is on ld.so path) and got everything working. And I don't understand this at all.
O, I finally got it!!! The source of the problem is automatic hwcaps labeling of shared libs based on directory names. This is done by glibc. Thus, a libfoo.so residing in /.../i386 directory gets marked with i386 architecture in the hwcaps mask, the same file residing in /.../i686 directory gets marked i686, and the same file in a randomly named directory doesn't get marked at all. This can be illustrated by running `ldconfig -p'. So, libjava.so references libverify.so. But they both sit in jre/lib/386 and are marked appropriately. But my machine is i686 and, as a result, the dynamic linker doesn't resolve anything in jre/lib/i386. ldd says libverify.so not found. Don't know if there is a way to configure ld-linux.so to work in my situation. So, I found a simple workaround: we make a jre/lib/i686 directory and create hardlinks for *.so from i386 there. Symbolic links don't fool the dynamic linker. cd $JAVA_HOME/jre/lib mkdir i686 ln i386/* i686/ That's it. And php-cgi ebuild now works with Java support.
Oh - that's a nice piece of investigation there. Re-assigning to the Java team to update their ebuilds. Best regards, Stu
can we even do hardlinks in portage?
Yes, ebuilds can do hardlinks. Use 'dohard' to create the link.
So, on x86, which arches do we need to support? i386, i486, i586 and i686, obviously, but any more?
*** Bug 98853 has been marked as a duplicate of this bug. ***
*** Bug 105813 has been marked as a duplicate of this bug. ***
*** Bug 118636 has been marked as a duplicate of this bug. ***
I've added a function to java.eclass to handle address this problem. Simply call fix-i386-dir <path to jre/lib/i386 dir> during src_install. What this does, is if we're on x86, and the chost isn't i386, it'll figure out what the right arch is (i486, i686, etc). Then it will move the i386 to this correct directory. It will also symlink this new dir back to i386 (if you don't do this, there seem to be problems finding libjava). So now, all the jdk/jre ebuilds need to be updated to use this. I figure this should go in ~arch, to make sure that this change doesn't affect anything adversely.
Fixed for blackdown-jdk-1.4.2.03-r2, sun-jdk-1.4.2.10-r2, and sun-jdk-1.5.0.06-r2.
Fixed in sun-jre-bin-1.5.0.06-r2, sun-jre-bin-1.4.2.10-r2, and blackdown-jre-1.4.2.03-r2.
We should be all set now.
After upgrading sun-jdk (1.5.0.06-r2): /opt/sun-jdk-1.5.0.06/bin/java -version Error: could not find libjava.so Error: could not find Java 2 Runtime Environment. Solution: cd /opt/sun-jdk-1.5.0.06/jre/lib ln -s i686 i386 /opt/sun-jdk-1.5.0.06/bin/java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
> /opt/sun-jdk-1.5.0.06/bin/java -version > Error: could not find libjava.so > Error: could not find Java 2 Runtime Environment. I can confirm, that this bug exists both for 1.4.2.10-r2 and 1.5.0.06-r2. # strace /opt/sun-jdk-1.4.2.10/bin/java execve("/opt/sun-jdk-1.4.2.10/bin/java", ["/opt/sun-jdk-1.4.2.10/bin/java"], [/* 47 vars */]) = 0 << CUT >> readlink("/proc/self/exe", "/opt/sun-jdk-1.4.2.10/bin/java", 4095) = 30 access("/opt/sun-jdk-1.4.2.10/lib/i386/libjava.so", F_OK) = -1 ENOENT (No such file or directory) access("/opt/sun-jdk-1.4.2.10/jre/lib/i386/libjava.so", F_OK) = -1 ENOENT (No such file or directory) write(2, "Error: could not find libjava.so"..., 33Error: could not find libjava.so ) = 33 write(2, "Error: could not find Java 2 Run"..., 50Error: could not find Java 2 Runtime Environment. ) = 50 exit_group(2) # strace /opt/sun-jdk-1.5.0.06/bin/java execve("/opt/sun-jdk-1.5.0.06/bin/java", ["/opt/sun-jdk-1.5.0.06/bin/java"], [/* 66 vars */]) = 0 << CUT >> readlink("/proc/self/exe", "/opt/sun-jdk-1.5.0.06/bin/java", 4095) = 30 access("/opt/sun-jdk-1.5.0.06/lib/i386/libjava.so", F_OK) = -1 ENOENT (No such file or directory) access("/opt/sun-jdk-1.5.0.06/jre/lib/i386/libjava.so", F_OK) = -1 ENOENT (No such file or directory) write(2, "Error: could not find libjava.so"..., 33Error: could not find libjava.so ) = 33 write(2, "Error: could not find Java 2 Run"..., 50Error: could not find Java 2 Runtime Environment. ) = 50 exit_group(2) Still, uname contains "i686": Linux vax 2.6.14-gentoo-r5 #5 SMP PREEMPT Tue Jan 10 11:19:35 MET 2006 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux > ln -s i686 i386 Works for both 1.4.2 and 1.5.0
(In reply to comment #21) (In reply to comment #22) Bug 119577
*** Bug 150410 has been marked as a duplicate of this bug. ***
