libjava issues with arm-linux-gcj from arm-linux-gcc 3.3.2

Fri Aug 19 00:34:00 GMT 2005

Nathan M wrote:
>>Is there any reason you can't just ask for the source?
>> I think the only thing I would need from CompuLab is the headers,
> right? (see below)
>>>>So I see, right. Well, I can see that gcc 3.3.2 was configured with
>>>> ../configure --target=arm-linux --disable-shared
>>--with-headers=/home/gerg/new-wave.xscale/linux-2.4.x/include --with-gnu-as --with-gnu-ld
>>--enable-multilib
>>>>AFAICS there's nothing to stop you from downloading the source of gcc
>>3.3.2, installing the headers from linux somewhere, and running
>>configure as above. That should beuild the lot.
>>> Ok, just to make sure I've got this right; I should follow this process, right:
>> 1. Obtain:
> - a fresh copy of the universal gcc-3.3.2 source from gnu.org (which
> should include javalib)
> - the headers from CompuLab
> 2. Copy the headers from CompuLab to:
> /home/username/new-wave.xscale/linux-2.4.x/include
> 3. Untar/unzip and change into the gcc-3.3.2 source directory
> 4. ./configure --target=arm-linux --disable-shared
> --with-headers=/home/username/new-wave.xscale/linux-2.4.x/include
> --with-gnu-as --with-gnu-ld --enable-multilib
>> And that should give me a new toolchain complete with java.lang
> compatible with arm-linux architecture? I assume the target board is
> missing all java libraries as well so I'll need to make sure any
> binaries I create with arm-linux-gcj are static, or otherwise put the
> libraries on the target board.

Correct.
>> In short I shouldn't need anything proprietary to arm-linux or
> CompuLab's board other than the headers, correct? The standard
> gcc-3.3.2 source should suffice, using the above process?
>>>> > Therefore my arm-linux-gcc 3.3.2 toolchain includes arm-linux-gcj
>> > in it's /bin section however there is no libjava binaries or source
>> > in the package. So somehow I still need to find and obtain a copy
>> > of libjava/java.lang compatible with Compulab's arm-linux, assuming
>> > such a package actually exists. Is libjava/java.lang typically
>> > platform specific?
>>>>Yes.
>>> I assume you mean the compiled binaries are platform specific but the
> sources should be universal? Otherwise the above process would not
> work properly.
>> Also, do I need worry about obtaining and cross compiling gnu
> classpath or anything related to that? Or is classpath included in
> the gcc source?

The GCC distribution contains everything you need. You don't need to 
get anything from classpath.
I would caution that it is possible that gcj/libgcj will not run very 
well on your platform. The non-existence of libjava/sysdeps/arm 
indicates to me that not very much hacking has been done to make 
arm-linux run very well.
If the state of the mips port in 3.3.x is any indication it might work, 
but many things that work on x86 were non-functional. I can see that 
ffi closures are still not implemented, so many things in 
java.lang.reflect will not work.
Many bugs in the java runtime have been fixed since 3.3.x, so as long as 
you are building your own gcj toolchain, you might want to think about 
using 3.4.4 or 4.0.1 instead.
Have fun with it.
David Daney.