Hi
If libjvm.so is in the same directory as avian-dynamic, then there's
no need for LD_LIBRARY_PATH to include that directory, we can just set
the rpath in avian-dynamic to $ORIGIN when linking it. Working patch
attached.
Regards
Damjan
We need to extract the OpenJDK classes into the build classpath
directory for the target platform before running the
bootimage-generator, or else it won't be able to find the classes.
This package name must match the URL protocol we use for loading
embedded resources, but OpenJDK's URL class won't tolerate underscores
in a protocol name. Also, I had not updated the names of the native
methods in avian.avianvmresource.Handler, leading to
UnsatisfiedLinkErrors when they were called.
set java.vm.version based on makefile version=
in order to display relevant OpenJDK -version information.
Signed-off-by: Matthias Klose <doko@ubuntu.com>
Signed-off-by: Xerxes Rånby <xerxes@zafena.se>
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.
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
A multilib-capable x86_64-w64-mingw32 compiler should work just fine,
but since we don't know if it's mutilib or not, we try the
i686-w64-mingw32 version first.
Using e.g. x86_64-w64-mingw32-gcc -m32 doesn't quite work at link time
when using Debian Wheezy's gcc-mingw-w64 package, due to the 32-bit
system libraries not being in the search path, so we use
i686-w64-mingw32-gcc instead.
We were not properly converting dots to slashes internally for package names
and we did not properly handle Method.getAnnotations and
Method.getAnnotation(Class<T>) on methods without any annotations.
Added some tests to cover these cases.
The usage statement for the bootimage-generator now looks like this:
build/linux-x86_64-bootimage/bootimage-generator \
-cp <classpath> \
-bootimage <bootimage file> \
-codeimage <codeimage file> \
[-entry <class name>[.<method name>[<method spec>]]] \
[-bootimage-symbols <start symbol name>:<end symbol name>] \
[-codeimage-symbols <start symbol name>:<end symbol name>]
