Re: About ARM-cross-compile

[Kai Ruottu <kai.ruottu@wippies.com>]

30.3.2012 19:03, Mao Ito kirjoitti:

> I got stuck on a problem.
> Actually, I could install "arm-eabi" cross-compiler for c, c++.
> The problem is about "arm-eabi-gcj" (i.e. for Java). "arm-elf" version
 > cross-compiler was successfully installed for c, c++, Java. But,
 > after that, I realized that my simulator does not accept OABI
 > binary code (i.e. binary code "arm-elf" compiler generates).
 > So, I need to install "arm-eabi" version cross-compiler because
 > the simulator can accept EABI binary code.
>
> So, recently, I was struggling to install "arm-eabi-gcj" into my
 > laptop. The problem is about "libgcj.jar" file.

Usually people don't build java for their compiler collection, only C
and C++, when the target is an embedded system like '*-elf' or your
chosen 'arm-eabi'. So these cases may be fully or somehow unsupported
:-(

Usually the problem isn't in getting '$target-gcj' or 'jc1' at all!
So your first claim, 'problem is about "arm-eabi-gcj"', sounds
untrue, this and the real Java compiler 'jc1' should succeed easily.
But using them to create 'libjava' ('--enable-libgcj') may be a big
problem and your second claim is more believable...

If looking at your "libjava arm-eabi" case via net search, the:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340

will appear. For curiosity I looked how well the recent gcc-4.6.3
works with the arm-eabi target. Some of the suggested fixes must
still be installed and producing 'libffi' enabled (compiling libjava
needs 'ffi.h', the only way was to fix 'configure' and remove
'target-libffi' from 'nonconfigdirs' in the 'arm-eabi' case). But
after these fixes the build still stopped at :

libtool: compile:  /home/src/gcc-4.6.3/build/./gcc/xgcc -shared-libgcc 
-B/home/src/gcc-4.6.3/build/./gcc -nostdinc++ 
-L/home/src/gcc-4.6.3/build/arm-eabi/libstdc++-v3/src 
-L/home/src/gcc-4.6.3/build/arm-eabi/libstdc++-v3/src/.libs -nostdinc 
-B/home/src/gcc-4.6.3/build/arm-eabi/newlib/ -isystem 
/home/src/gcc-4.6.3/build/arm-eabi/newlib/targ-include -isystem 
/home/src/gcc-4.6.3/newlib/libc/include 
-B/home/src/gcc-4.6.3/build/arm-eabi/libgloss/arm 
-L/home/src/gcc-4.6.3/build/arm-eabi/libgloss/libnosys 
-L/home/src/gcc-4.6.3/libgloss/arm -B/opt/cross/arm-eabi/bin/ 
-B/opt/cross/arm-eabi/lib/ -isystem /opt/cross/arm-eabi/include -isystem 
/opt/cross/arm-eabi/sys-include -DHAVE_CONFIG_H -I. -I../../../libjava 
-I./include -I./gcj -I../../../libjava -Iinclude 
-I../../../libjava/include -I../../../libjava/classpath/include 
-Iclasspath/include -I../../../libjava/classpath/native/fdlibm 
-I../../../libjava/../boehm-gc/include -I../boehm-gc/include 
-I../../../libjava/.././libjava/../gcc -I../../../libjava/../zlib 
-fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum 
-D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE 
-DPREFIX=\"/opt/cross\" 
-DTOOLEXECLIBDIR=\"/opt/cross/lib/gcc/arm-eabi/4.6.3\" 
-DJAVA_HOME=\"/opt/cross\" 
-DBOOT_CLASS_PATH=\"/opt/cross/share/java/libgcj-4.6.3.jar\" 
-DJAVA_EXT_DIRS=\"/opt/cross/share/java/ext\" 
-DGCJ_ENDORSED_DIRS=\"/opt/cross/share/java/gcj-endorsed\" 
-DGCJ_VERSIONED_LIBDIR=\"/opt/cross/lib/gcj-4.6.3-12\" 
-DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" 
-DLIBGCJ_DEFAULT_DATABASE=\"/opt/cross/lib/gcj-4.6.3-12/classmap.db\" 
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.6.3-12/classmap.db\" -g -Os 
-MT java/net/natVMInetAddress.lo -MD -MP -MF 
java/net/.deps/natVMInetAddress.Tpo -c java/net/natVMInetAddress.cc -o 
java/net/natVMInetAddress.o
java/net/natVMInetAddress.cc:12:1: error: 'jstring' does not name a type
java/net/natVMInetAddress.cc:18:1: error: 'jbyteArray' does not name a type
java/net/natVMInetAddress.cc:24:1: error: 'jstring' does not name a type
java/net/natVMInetAddress.cc:30:1: error: 'JArray' does not name a type
java/net/natVMInetAddress.cc:36:1: error: 'jbyteArray' does not name a type
make[3]: *** [java/net/natVMInetAddress.lo] Virhe 1
make[3]: Poistutaan hakemistosta 
"/home/src/gcc-4.6.3/build/arm-eabi/libjava"

My interest ended here :-(  Continuing from this could be your
homework...

With gcc-4.7.0 the situation could be even worse :

/bin/bash ../../libtool --tag=CC   --mode=compile 
/home/src/gcc-4.7.0/build/./gcc/xgcc -B/home/src/gcc-4.7.0/build/./gcc/ 
-nostdinc -B/home/src/gcc-4.7.0/build/arm-eabi/newlib/ -isystem 
/home/src/gcc-4.7.0/build/arm-eabi/newlib/targ-include -isystem 
/home/src/gcc-4.7.0/newlib/libc/include 
-B/home/src/gcc-4.7.0/build/arm-eabi/libgloss/arm 
-L/home/src/gcc-4.7.0/build/arm-eabi/libgloss/libnosys 
-L/home/src/gcc-4.7.0/libgloss/arm -B/opt/cross/arm-eabi/bin/ 
-B/opt/cross/arm-eabi/lib/ -isystem /opt/cross/arm-eabi/include -isystem 
/opt/cross/arm-eabi/sys-include    -DHAVE_CONFIG_H -I. 
-I../../../../../../libjava/classpath/native/fdlibm -I../../include 
-fexceptions -fasynchronous-unwind-tables -g -Os -MT dtoa.lo -MD -MP -MF 
.deps/dtoa.Tpo -c -o dtoa.lo 
../../../../../../libjava/classpath/native/fdlibm/dtoa.c
libtool: compile: not configured to build any kind of library
libtool: compile: See the libtool documentation for more information.
libtool: compile: Fatal configuration error.
make[5]: *** [dtoa.lo] Virhe 1

> I could download "libgcj-4.1.2-51.el5.x86_64.rpm" from this web-site
> The problem is that this is RPM file so that I need to get
 > "RPM-GPG-KEY" for this rpm file to unlock it.

How the previous is related to getting the Java toolchain for
'arm-eabi'?  Seemingly one can compile an existing '.jar' file
(some target-independent bytecode?) for some specific architecture
with its own '$target-gcj'. Here the goal could be compiling a
libgcj made for Linux/x86_64 for 'arm-eabi'?  I would expect a
'libgcj' made for some target being very target-dependent and
not a '.jar' file at all :-(