23579 2003-06-27 04:44 0000 libverify.so not found; also ld.so.conf error 2006-10-07 13:25:52 0000 1 1 1 Unclassified Gentoo Linux Development unspecified All Linux RESOLVED FIXED P2 blocker --- 119577 15650 1 stuart@gentoo.org java@gentoo.org dliana@frontiernet.net dsomers@trevezel.com fischer@unix-ag.uni-kl.de Heinrich.Nirschl@gmail.com peter.slizik@pobox.sk rossi.f@inwind.it stuart@gentoo.org 2003-06-27 04:44:29 0000 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. stuart@gentoo.org 2003-06-27 10:56:26 0000 :( 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 tberman@gentoo.org 2003-07-13 17:45:45 0000 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. acooks@gentoo.org 2003-11-25 00:08:25 0000 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. acooks@gentoo.org 2003-11-25 00:11:39 0000 Whoa, sorry, I'll open my eyes next time! axxo@gentoo.org 2004-07-29 15:26:01 0000 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 axxo@gentoo.org 2004-08-30 02:09:15 0000 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 a_taranov@custis.ru 2005-02-16 23:30:16 0000 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. a_taranov@custis.ru 2005-02-17 02:19:50 0000 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. a_taranov@custis.ru 2005-02-17 03:21:14 0000 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. stuart@gentoo.org 2005-02-17 03:30:28 0000 Oh - that's a nice piece of investigation there. Re-assigning to the Java team to update their ebuilds. Best regards, Stu axxo@gentoo.org 2005-05-18 04:04:44 0000 can we even do hardlinks in portage? compnerd@gentoo.org 2005-07-05 21:04:49 0000 Yes, ebuilds can do hardlinks. Use 'dohard' to create the link. karltk@gentoo.org 2005-07-14 10:44:40 0000 So, on x86, which arches do we need to support? i386, i486, i586 and i686, obviously, but any more? axxo@gentoo.org 2005-09-10 12:04:29 0000 *** Bug 98853 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2005-09-13 09:22:44 0000 *** Bug 105813 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-01-11 02:49:57 0000 *** Bug 118636 has been marked as a duplicate of this bug. *** nichoj@gentoo.org 2006-01-18 19:56:38 0000 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. nichoj@gentoo.org 2006-01-18 20:51:50 0000 Fixed for blackdown-jdk-1.4.2.03-r2, sun-jdk-1.4.2.10-r2, and sun-jdk-1.5.0.06-r2. nichoj@gentoo.org 2006-01-19 17:19:01 0000 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. nichoj@gentoo.org 2006-01-19 20:33:35 0000 We should be all set now. andrei.ivanov@gmail.com 2006-01-20 00:18:40 0000 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) fischer@unix-ag.uni-kl.de 2006-01-20 00:47:22 0000 > /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 jakub@gentoo.org 2006-01-20 03:19:15 0000 (In reply to comment #21) (In reply to comment #22) Bug 119577 jakub@gentoo.org 2006-10-07 13:25:52 0000 *** Bug 150410 has been marked as a duplicate of this bug. ***