From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roel Janssen Subject: Re: IcedTea is not linking correctly with libjvm.so Date: Sun, 22 Oct 2017 17:55:34 +0200 Message-ID: <87mv4jqirt.fsf@gnu.org> References: <87y3o56kve.fsf@gnu.org> <877evokzir.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e6IbG-0002zm-4i for guix-devel@gnu.org; Sun, 22 Oct 2017 11:55:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e6IbC-0006Z9-8i for guix-devel@gnu.org; Sun, 22 Oct 2017 11:55:42 -0400 In-reply-to: <877evokzir.fsf@gmail.com> 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: Chris Marusich Cc: guix-devel Chris Marusich writes: > Roel Janssen writes: > >> 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. > > (1) seems better than (2) if possible, but either of those solutions > seem OK to me. But to be honest, I don't understand why this isn't a > problem for icedtea outside of Guix. What are we doing that is > different which prevents the library from being found? Thanks for your reply! I agree that (1) would be better than (2). The only problem I see with this is that I don't see how to achieve (1), but I do see how to achieve (2). I tried running that Java app with CentOS's Java (openjdk 1.7.0), and it has the exact same problem: $ ldd /usr/lib/jvm/java-1.7.0-openjdk/jre/lib/amd64/libnet.so linux-vdso.so.1 => (0x00007ffcc153d000) libjvm.so => not found libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0b70d7e000) libgconf-2.so.4 => /lib64/libgconf-2.so.4 (0x00007f0b70b4d000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f0b70816000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f0b705c5000) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f0b70245000) libjava.so => /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.121-2.6.8.0.el7_3.x86_64/jre/lib/amd64/./libjava.so (0x00007f0b70019000) libc.so.6 => /lib64/libc.so.6 (0x00007f0b6fc57000) /lib64/ld-linux-x86-64.so.2 (0x00007f0b711ce000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f0b6fa53000) libdbus-glib-1.so.2 => /lib64/libdbus-glib-1.so.2 (0x00007f0b6f82b000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f0b6f5e2000) libffi.so.6 => /lib64/libffi.so.6 (0x00007f0b6f3da000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f0b6f1d6000) libz.so.1 => /lib64/libz.so.1 (0x00007f0b6efbf000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f0b6ed98000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f0b6eb7e000) libjvm.so => not found libverify.so => /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.121-2.6.8.0.el7_3.x86_64/jre/lib/amd64/./libverify.so (0x00007f0b6e96e000) librt.so.1 => /lib64/librt.so.1 (0x00007f0b6e765000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f0b6e504000) libjvm.so => not found > > Solution (3) feels like more of a hack than (2), so I'm not sure about > it. Maybe other have other opinions? I agree that we should avoid solution (3). Kind regards, Roel Janssen