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 :-(
