guix-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]