From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roel Janssen Subject: Re: IcedTea is not linking correctly with libjvm.so Date: Tue, 24 Oct 2017 13:46:14 +0200 Message-ID: <87bmkwu61j.fsf@gnu.org> References: <87y3o56kve.fsf@gnu.org> <877evokzir.fsf@gmail.com> <87mv4jqirt.fsf@gnu.org> <87fuaa536t.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e6xf9-0004cA-QN for guix-devel@gnu.org; Tue, 24 Oct 2017 07:46:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e6xf6-0001mX-Lg for guix-devel@gnu.org; Tue, 24 Oct 2017 07:46:27 -0400 In-reply-to: <87fuaa536t.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 --=-=-= Content-Type: text/plain Chris Marusich writes: > Roel Janssen writes: > >> 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 > > Can you share a minimal program that reproduces the issue? If it > happens on Guix's Java, built with Icedtea, and also on another > distro's, too, then maybe it's a genuine bug that can be fixed upstream. Unfortunately, I don't have a simple example to reproduce it. However, it looks a lot like this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1212151 The program producing the error can be found here: https://github.com/hartwigmedical/hmftools For which I have a package here: https://github.com/UMCUGenetics/guix-additions/blob/master/umcu/packages/hmf.scm#L117 However, it needs various data inputs before the tool will run. Hence, the problem with making a simple example to reproduce it. I attached a patch for solution (2), which seems to work. On the output directory: $ $ ldd /gnu/store/0p35h1dq956h4axal8cc9as1y7qxchqv-icedtea-2.6.11/lib/amd64/libnet.so linux-vdso.so.1 (0x00007ffdda9ab000) libjvm.so => /gnu/store/0p35h1dq956h4axal8cc9as1y7qxchqv-icedtea-2.6.11/lib/amd64/./libjvm.so (0x00007f2def98c000) libpthread.so.0 => /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/libpthread.so.0 (0x00007f2def76e000) libdl.so.2 => /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/libdl.so.2 (0x00007f2def56a000) libgio-2.0.so.0 => /gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/libgio-2.0.so.0 (0x00007f2def1d3000) libgobject-2.0.so.0 => /gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/libgobject-2.0.so.0 (0x00007f2deef81000) libglib-2.0.so.0 => /gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/libglib-2.0.so.0 (0x00007f2deec6e000) libjava.so => /gnu/store/0p35h1dq956h4axal8cc9as1y7qxchqv-icedtea-2.6.11/lib/amd64/./libjava.so (0x00007f2deea42000) libc.so.6 => /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/libc.so.6 (0x00007f2dee6a3000) libgcc_s.so.1 => /gnu/store/3x53yv4v144c9xp02rs64z7j597kkqax-gcc-5.4.0-lib/lib/libgcc_s.so.1 (0x00007f2dee48c000) libstdc++.so.6 => /gnu/store/3x53yv4v144c9xp02rs64z7j597kkqax-gcc-5.4.0-lib/lib/libstdc++.so.6 (0x00007f2dee112000) libm.so.6 => /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/libm.so.6 (0x00007f2dede00000) /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/ld-linux-x86-64.so.2 (0x00007f2df09b4000) libffi.so.6 => /gnu/store/jnbb8ffxxvrw2b4z18zn0g08kqk9rsgl-libffi-3.2.1/lib/libffi.so.6 (0x00007f2dedbf5000) libgmodule-2.0.so.0 => /gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/libgmodule-2.0.so.0 (0x00007f2ded9f1000) libpcre.so.1 => /gnu/store/3amb8hw38k2jv604pb87am8v9r17fczi-pcre-8.41/lib/libpcre.so.1 (0x00007f2ded780000) libz.so.1 => /gnu/store/sfx1wh27i6gsrk21p87rdyikc64v7d51-zlib-1.2.11/lib/libz.so.1 (0x00007f2ded565000) libresolv.so.2 => /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/libresolv.so.2 (0x00007f2ded34f000) libmount.so.1 => /gnu/store/zbywrj6klakskj0sppq56viqh9l56jl0-util-linux-2.30.1/lib/libmount.so.1 (0x00007f2ded0fd000) libblkid.so.1 => /gnu/store/zbywrj6klakskj0sppq56viqh9l56jl0-util-linux-2.30.1/lib/libblkid.so.1 (0x00007f2deceb5000) libuuid.so.1 => /gnu/store/zbywrj6klakskj0sppq56viqh9l56jl0-util-linux-2.30.1/lib/libuuid.so.1 (0x00007f2deccb0000) librt.so.1 => /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/librt.so.1 (0x00007f2decaa8000) libverify.so => /gnu/store/0p35h1dq956h4axal8cc9as1y7qxchqv-icedtea-2.6.11/lib/amd64/./libverify.so (0x00007f2dec899000) I'd like to put this solution in place until we find out how to apply solution (1). The difference on the output is one symbolic link, so the impact is low. This patch fixes this issue for icedtea-7 and icedtea-8. Is it OK to push this patch? Thanks for your time! Kind regards, Roel Janssen --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-gnu-java-Fix-libjvm.so-linkage-problem-in-icedtea-7.patch >From a9deda0a7b6162b037ff9ffb08135275c06b340c Mon Sep 17 00:00:00 2001 From: Roel Janssen Date: Tue, 24 Oct 2017 12:20:26 +0200 Subject: [PATCH] gnu: java: Fix libjvm.so linkage problem in icedtea-7. * gnu/packages/java.scm (icedtea-7): Add phase to create a symbolic link to libjvm.so. --- gnu/packages/java.scm | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm index 95fba20e8..81cfdc132 100644 --- a/gnu/packages/java.scm +++ b/gnu/packages/java.scm @@ -1404,6 +1404,18 @@ bootstrapping purposes.") (copy-recursively "openjdk.build/j2re-image" jre) (copy-recursively "openjdk.build/j2sdk-image" jdk)) #t)) + ;; Some of the libraries in the lib/amd64 folder link to libjvm.so. But that + ;; shared object is located in the server/ folder, so it cannot be found. + ;; This phase creates a symbolic link in the lib/amd64 folder so that the + ;; other libraries can find it. + ;; + ;; See https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00169.html + (add-after 'install 'install-libjvm + (lambda* (#:key inputs outputs #:allow-other-keys) + (let* ((lib-path (string-append (assoc-ref outputs "out") "/lib/amd64"))) + (system* "ln" "--symbolic" + (string-append lib-path "/server/libjvm.so") + (string-append lib-path "/libjvm.so"))))) ;; By default IcedTea only generates an empty keystore. In order to ;; be able to use certificates in Java programs we need to generate a ;; keystore from a set of certificates. For convenience we use the -- 2.14.2 --=-=-=--