I'm working on some software that uses libsodium for cryptography…in Java. It has worked fine for me on both macOS 10.11/10.12 and Ubuntu Server 16.04. When I try to run my software on an Amazon EC2 Instance with Amazon Linux (uname -a
returns Linux ip-$IPADDR 4.4.19-29.55.amzn1.x86_64 #1 SMP Mon Aug 29 23:29:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
) I get this error:
java.lang.UnsatisfiedLinkError: /home/ec2-user/myproject/target/classes/linux-x86-64/libsodiumjni.so: /usr/lib64/libc.so: invalid ELF header
Turns out libc.so
is an ASCII file on this machine:
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
I tried running my code with argument -Djava.library.path=/lib64/:…:$NORMALLIBRARYPATH
to hopefully get the loader to try /lib64/libc.so.6
instead but it didn't work.
The section of code that causes libsodiumjni.so to be loaded is:
import com.sun.jna.Native;
…
File libraryFile = Native.extractFromResourcePath(libraryName);
System.load(libraryFile.getAbsolutePath());
Inside of my project, the directory structure includes the library files in paths that JNA's Native class understands:
src/main/resources
├── darwin
│ └── libsodiumjni.dylib
└── linux-x86-64
└── libsodiumjni.so
On a lark I deleted the ASCII libc.so and replaced it with a symlink to /lib64/libc-2.17.so and got a slightly different error:
java.lang.UnsatisfiedLinkError: /home/ec2-user/myproject/target/classes/linux-x86-64/libsodiumjni.so: /lib64/libc.so.6: version `LIBC' not found (required by /home/ec2-user/myproject/target/classes/linux-x86-64/libsodiumjni.so
I'm really unsure what to do about this. I'd really like to continue using libsodium (through libsodium-jni) but I'm hitting a wall here. Might have to switch to a different library since many-platform compatibility is important for this project.