Error compiling for java

Thu Dec 14 09:53:00 GMT 2006

David Daney wrote:
> There is something wrong either with your libc or your cross-compiler 
> configuration commands, I am not sure which.
>> Your libc build should include all the necessary headers before you 
> start configuring and building the cross compiler.
 This is the expectation: the target C library already exists when one 
starts to produce a crosscompiler for the
target! This is true when the target system exists already and then one 
can simply copy the target C library
from it. Producing the target C library has absolutely nothing to do 
with the GCC production!
> You could try asking on crossgcc@sourceware.org as it appears that you 
> are using crosstool. Many of the crosstool developers read that list 
> and are generally fairly responsive to questions.

 "Those who know how to do something will do it. Those who don't know 
how to do that can only give
advices for others to do that!" Old Karelian wisdom... The crossgcc 
people may be responsive but whether
they really know "how to do something" isn't that clear :-(
 The first thing to understand is that these people have a blind faith 
that "reinventing the wheel", ie replacing
the existing (expected to be) thoroughly tested target stuff with 
totally self-made stuff would lead to a better
result than using the original. Using the original is always a safe 
bet, if one replaces it, then one should know
that the replacement is really better! Ok, I myself was one of those 
who tried to tell people that putting
"pirate parts", as the words then were, into IBM etc. PCs instead of 
using the expensive "originals" would lead
into a better result! The same thing with the DEC VAX'es, using much 
cheaper NSC memory boards for instance.
Or using a FoxBase, a dBXL or some other "dBASE clone" instead of the 
original. Or using a Basmark BASIC
(32-bit) instead of the original Microsoft (16-bit) one on PC Unices. 
Or using Linux instead of the "original"
Unix. In these cases I had a thought that the replacement should be 
better than the original....
 This far I haven't seen any evidence that the self-made "Kegelian 
Linux" parts really are better than their Red
Hat, SuSE, Debian, MontaVista etc. made "originals". So when producing 
crosstoolchains for these existing
Linuces my advice would be to use their original parts for the target, 
like their glibcs, X11-libs, Gnome and
KDE libraries instead of building oneself replacements for these. And 
do the same even with the 'crosstool'
or something made existing "hobby" things like OpenWRT... A recent case 
with Java showed that one really
cannot mix the existing installed OpenWRT runtimes with a self-made 
'libgcj.so' when this was produced to
be in sync with the self-made uClibc, not with the original installed 
OpenWRT uClibc.
 Of course everyone is free to experiment with self-made components 
but first one could check that things
are working when using the (expected to be freely available) originals !
>> /opt/crosstool/gcc-4.1.0-glibc-2.3.5/powerpc-750-linux-gnu/powerpc-750-linux 
>>>> > -gnu/include/sys/syscall.h:32:27: error: bits/syscall.h: No such 
>> file or
>> > directory
 Whether there is any existing Linux/PPC-750 system in the Mudit case, 
is still unclear :-( However this
thing is just the one which states the sanity to use "crosstool" : to 
create the toolchain from scratch (if one
really sees sanity even in this - I don't because there are so many 
"suitable" Linux/PPC bootstrap parts)
and then use it to create the whole target Linux system from scratch ! 
If one is not going to create the
target Linux system from scratch, what on earth one thinks doing when 
using the "crosstool"?