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
