[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IcedTea is not linking correctly with libjvm.so
From: |
Roel Janssen |
Subject: |
Re: IcedTea is not linking correctly with libjvm.so |
Date: |
Sun, 22 Oct 2017 17:55:34 +0200 |
User-agent: |
mu4e 0.9.18; emacs 25.1.1 |
Chris Marusich writes:
> Roel Janssen <address@hidden> 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