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>]
When link time optimization is enabled, we need to remind the compiler
that we're targeting i586 when linking so it can resolve atomic
operations like __sync_bool_compare_and_swap.
When link time optimization is enabled, we need to remind the compiler
that we're targeting i586 when linking so it can resolve atomic
operations like __sync_bool_compare_and_swap.
The JRE lib dir for OpenJDK 7 on OS X seems to be just "lib", not
e.g. "lib/amd64" by default, so we use that now. Also, the default
library compatibility version for libjvm.dylib is 0.0.0, but OpenJDK
wants 1.0.0, so we set it explicitly.
