Error compiling for java
Goel, Mudit (Mudit)
Wed Dec 20 10:00:00 GMT 2006
Thanx to Gene Sally for digging out a post with similar issue seen one
year back. The crosstool.sh needs to be modified to overcome this
Now I have been able to succesfully build gcj for ppc750.
From: Kai Ruottu [mailto:firstname.lastname@example.org]
Sent: Thursday, December 14, 2006 3:25 PM
To: Goel, Mudit (Mudit)
Subject: Re: Error compiling for java
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 email@example.com 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
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 !
>> > -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
If one is not going to create the
target Linux system from scratch, what on earth one thinks doing when
using the "crosstool"?
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc