Hello, I'm trying to crosscompile the JamVM and GNU Classpath for this platform: - Xscale processor 533MHz Intel IXP42x - Montavista 4.01 - Linux 2.6.10 kernel I'm using the xscale_gcc_be compiler-tool, provided by MontaVista. I configure Classpath as follows: ./configure CFLAGS="-L/work/montavista/pro/devkit/arm/xscale_be/target/usr/lib -L/work/montavista/pro/devkit/arm/xscale_be/lib -L/app/COMMON/zlib-1.2.$ Everything looks fine, but some java apps do not work. I traced the errors of one of them, discovering the conversion of java types to c types in native calls fails in some way. Example: when in gnu.java.nioVMChannel the method seek(long l) is called with argument '0', the corresponding jlong does not hold the value 0, but this: (HEX) 00 00 00 00 00 05 67 E4. What can I do about this, do I use the wrong compiler flags, any help is appreciated. I'm am fairly new to the big crosscompiling thing. regards, dvrslype
There are some ugly bugs in long and double conversions on ARM (version 0.97). This: timebase = ((double)((long)(timebase*1000)))/1000; where timebase is a double, returns zero for all values of timebase that I've tried (say 0.1-2). This works correctly: timebase = ((double)((int)(timebase*1000)))/1000; This: Double.toString(currentValue); where currentValue is a double also returns very strange strings on ARM. Strings including non-numeric characters and just fundamentally wrong. A work around is to use a DecimalFormatter, eg: format = DecimalFormat.getNumberInstance(locale); return format.format(currentValue); returns the correct string. I assume that these just represent test cases for a deeper problem. The behavior has been true since at least 0.95 (haven't tested anything prior to this) and shows up with a number of JVMs (eg Sable and IKVM). Tested on the NSLU2 with a variety of distributions (Debian, OpenSlug, Angstrom(?)).