This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About ARM-cross-compile

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:

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/ -o java/net/natVMInetAddress.o
java/net/ error: 'jstring' does not name a type
java/net/ error: 'jbyteArray' does not name a type
java/net/ error: 'jstring' does not name a type
java/net/ error: 'JArray' does not name a type
java/net/ 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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]