This is the mail archive of the java@gcc.gnu.org mailing list for the Java 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: 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 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"?



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