From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roel Janssen Subject: IcedTea is not linking correctly with libjvm.so Date: Sat, 21 Oct 2017 09:05:57 +0200 Message-ID: <87y3o56kve.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5nrJ-00033V-PA for guix-devel@gnu.org; Sat, 21 Oct 2017 03:06:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5nrG-0005Wh-JM for guix-devel@gnu.org; Sat, 21 Oct 2017 03:06:13 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5nrG-0005Wb-Ft for guix-devel@gnu.org; Sat, 21 Oct 2017 03:06:10 -0400 Received: from ip112-245-209-87.adsl2.static.versatel.nl ([87.209.245.112]:58736 helo=yellowstone) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e5nrF-0001ls-UP for guix-devel@gnu.org; Sat, 21 Oct 2017 03:06:10 -0400 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel Dear Guix, I ran into a problem with a Java program running with Guix's icedtea-3. The error message looks like this: Exception in thread "main" java.lang.UnsatisfiedLinkError: /gnu/store/q9ad5zvxpm2spiddcj01sw3jkm5vpgva-icedtea-3.5.1/lib/amd64/libnet.so: /gnu/store/q9ad5zvxpm2spiddcj01sw3jkm5vpgva-icedtea-3.5.1/lib/amd64/libnet.so: failed to map segment from shared object at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at java.net.InetAddress$1.run(InetAddress.java:294) at java.net.InetAddress$1.run(InetAddress.java:292) at java.security.AccessController.doPrivileged(Native Method) at java.net.InetAddress.(InetAddress.java:291) at org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:53) at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:539) at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617) at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634) at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229) at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152) at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551) ... Looking into this shared object, I found that it cannot find libjvm.so: $ ldd /gnu/store/q9ad5zvxpm2spiddcj01sw3jkm5vpgva-icedtea-3.5.1/lib/amd64/libnet.so linux-vdso.so.1 => (0x00007ffe355ab000) libdl.so.2 => /gnu/store/20jhhjzgyqkiw1078cyy3891amqm8d4f-glibc-2.25/lib/libdl.so.2 (0x00007f3984931000) libjvm.so => not found libpthread.so.0 => /gnu/store/20jhhjzgyqkiw1078cyy3891amqm8d4f-glibc-2.25/lib/libpthread.so.0 (0x00007f39846f8000) libjava.so => /gnu/store/q9ad5zvxpm2spiddcj01sw3jkm5vpgva-icedtea-3.5.1/lib/amd64/libjava.so (0x00007f39844cc000) libgcc_s.so.1 => /gnu/store/0ss2akh5grfdfqnik6mm3lj4yyyb08np-gcc-5.4.0-lib/lib/libgcc_s.so.1 (0x00007f39842b4000) libc.so.6 => /gnu/store/20jhhjzgyqkiw1078cyy3891amqm8d4f-glibc-2.25/lib/libc.so.6 (0x00007f3983f15000) /lib64/ld-linux-x86-64.so.2 (0x00007f3984d4d000) libjvm.so => not found libverify.so => /gnu/store/q9ad5zvxpm2spiddcj01sw3jkm5vpgva-icedtea-3.5.1/lib/amd64/libverify.so (0x00007f3983d05000) libjvm.so => not found It seems that libjvm.so is in the lib/amd64/server folder of the icedtea package, so after setting LD_LIBRARY_PATH, the application runs fine: $ export LD_LIBRARY_PATH=/gnu/store/q9ad5zvxpm2spiddcj01sw3jkm5vpgva-icedtea-3.5.1/lib/amd64/server I looked into the package recipe, but I cannot find a place where a change in the compilation process could fix this problem. My only guess is that in the 'patch-jni-libs phase, we could change the way dynamically loaded libraries are found. The way I see it, we could do three things: 1. Fix the recipe to make sure libjvm.so is found, and thus libnet.so is linked correctly. 2. Copy or make a symlink of libjvm.so to the parent directory (lib/amd64), where the other libraries are. Maybe then libnet.so can find libjvm.so. 3. Propagate LD_LIBRARY_PATH with a path to lib/amd64/server. It would work like in my quick test, but this is my least favorite solution. Which way would be preferable? I can prepare a patch for option 2, and see if that works. But maybe option 1 would be better. Thanks for your time. Kind regards, Roel Janssen