On the ARM platform, Avian compiled to use OpenJDK gets this error on
startup:
java/lang/UnsatisfiedLinkError: no zip in java.library.path
at java/lang/ClassLoader.loadLibrary (line 1860)
at java/lang/Runtime.loadLibrary0 (line 845)
at java/lang/System.loadLibrary (line 1084)
at java/lang/System.initializeSystemClass (line 1145)
Using strace shows why:
[pid 22431]
stat64("/usr/lib/jvm/java-7-openjdk-armhf/jre/lib/i386/libzip.so",
0xbee377e0) = -1 ENOENT (No such file or directory)
The attached patch uses "arm" instead of "i386" in that path. This fixes the
problem.
I get this error when compiling with "make openjdk=...." on both x86_64 and
arm:
compiling test classes
test/Arrays.java:90: error: reference to equals is ambiguous, both method
equals(float[],float[]) in Arrays and method equals(Object[],Object[]) in
Arrays match
expect(java.util.Arrays.equals(null, null));
test/Arrays.java:95: error: reference to hashCode is ambiguous, both method
hashCode(double[]) in Arrays and method hashCode(Object[]) in Arrays match
java.util.Arrays.hashCode(null);
The attached patch fixes this.
Linux, FreeBSD, and QNX all use ELF, so no need to distinguish between
them when generating object files. To avoid confusion, I've switch
from using operating system names to using binary format names where
applicable.
The existing code handled such odd switch statements correctly in the
JIT case, but did the wrong thing for the AOT case, leading to an
assertion failure later on.
When we skip a single-precision register to ensure a double-precision
load is aligned, we need to remember that in case we see another
single-precision argument later on, which we must backfill into that
register we skipped according to the ABI.
This ABI's calling convention passes arguments and returns results
using VFP registers, so we need to tweak vmNativeCall to match it.
Thanks to Damjan Jovanovic for pointing this out and providing an
initial patch.
All but one test is passing. The failure is due to the fact that QNX
doesn't (in general) support calling fork(2) from a multithreaded
process. Thus, we'll need to use spawn instead of fork/exec on QNX,
which I'll attempt in a later commit.
http://www.qnx.com/developers/docs/6.4.1/neutrino/getting_started/s1_procs.html
