IcedTea is not linking correctly with libjvm.so

[Roel Janssen]

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.<clinit>(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