Cross-compiling libjava
Ranjit Mathew
rmathew@hotmail.com
Mon Nov 4 04:46:00 GMT 2002
Hi,
This discussion strikes right at the heart of the problem
I'm currently facing and trying to sort out: I build
GCJ for MinGW first as a cross-compiler (host=build=linux,
target=mingw32) and then as a crossed-native (coined
"Australian Cross" by David on this list) compiler
(host=target=mingw32, build=linux) using the cross-compiler
created earlier.
Do read on for my 2p worth of comments...
Tom Tromey wrote:
> Suppose you have a unified build tree where newlib is built as part of
> the tree. In this situation, newlib is a target library, a sibling of
> libgcj. In this case, at the time that the libgcj configure script
> runs, newlib hasn't yet been built, and so link tests will fail.
From looking at the top-level GCC Makefile, it seems that newlib will
be built before libjava - though it's not a direct dependency, isn't
it assured that newlib would be built before libjava? Or would
parallel makes break this? Even then, I guess there should be
some way to "serialise" this.
> I think when using newlib we must maintain the no-link rule. If
> Anthony is reading, maybe he can speak more to this; I know he does a
> newlib-based build from time to time.
With the ordering of the make targets as I noted above, does it
still break if we try to link against newlib?
Post GCC 3.2, this conditional now reads "with_newlib" instead
of "with_cross_host" - this even more incorrect. IMHO, we should
stick with the conditional for "with_cross_host".
The GCC toplevel configure sets the flag --with-cross-host=xyz
for the benefit of target libraries because for them host==target.
If libgcj is being built separately from GCC, you would then
have to supply this flag. Two things worth mentioning:
1. The GCC toplevel configure says --with-cross-host is deprecated
and target libraries should use some other mechanism, but doesn't
suggest any alternative. What's wrong with using this flag?
2. I at least, have not been able to build libgcj separately as it
seems to make too many assumptions about things (for example
fastjar) being "around" (in sibling build folders) during build.
IMO, this part of the configure script should have a
structure like the following pseudo-code:
/* Note: host *has* to be equal to target ("Duh!", but still). */
if( with_cross_host)
{
if( with_cross_host == build)
{
/* ordinary cross */
}
else
{
/* canadian cross */
}
}
else if( build != host)
{
/* crossed native (or australian cross) */
}
else
{
/* native */
}
If this structure looks fine, we can go about filling
it under these assumptions (Local compiler is the
compiler used to build GCJ - not necessarily that
used to build libgcj):
1. Native => Local and Built compilers can compile,
link and create locally executable programs.
libgcj is built by the Built compiler.
"binPrograms" must be created.
2. Ordinary Cross => Local compiler is native, Built
compiler can be used to only compile and link
programs.
libgcj is built by the Built compiler.
"binPrograms" should not be created.
3. Canadian Cross => Local compiler is a cross compiler,
Built compiler can not be used for anything useful.
libgcj is built by the Local compiler.
"binPrograms" should not be created.
4. Crossed Native => Local compiler is a cross compiler,
Built compiler can not be used for anything useful.
libgcj is built by the Local compiler.
"binPrograms" must be created.
Does this sound OK? Did I miss out anything? (apart from
the details that is)
Sincerely Yours,
Ranjit.
--
Ranjit Mathew Email: rmathew AT hotmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/
More information about the Java
mailing list