This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Cross Compiling Issues in GCJ 3.3
- From: Ranjit Mathew <rmathew at hotmail dot com>
- To: java at gcc dot gnu dot org
- Date: Fri, 17 Jan 2003 10:52:41 +0530
- Subject: Cross Compiling Issues in GCJ 3.3
Hi,
IMHO, the following patch has broken the cross-compiling
support of GCJ for non-embedded systems as compared to 3.2:
----------------------------- 8< -----------------------------
2002-06-04 H.J. Lu (hjl@gnu.org)
* configure.in (--with-newlib): New option:
Check ${with_newlib} instead of ${with_cross_host} for newlib.
(HAVE_PROC_SELF_EXE): Defined to 1 only for cross compiling to
Linux.
* configure: Regenerated.
----------------------------- 8< -----------------------------
Because of this, while cross-compiling for MinGW from Linux, I
find the build marked "NATIVE"(!!) and therefore "bin_PROGRAMS"
(gij.exe, rmic.exe, etc.) are generated which make no sense for a
cross-compiler toolchain.
The situation gets much worse for a crossed-native build...
Does anyone remember why this change had to be done? Can it
not be reversed (not the whole patch, but just the check
modification)?
If I refer to the following document in the GCC documentation:
http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html
it says that target libraries should use $with_cross_host to
check for the "real" host, as $host == $target for them.
So the original check was indeed correct, IMHO.
Or am I missing something here?
As an aside, the gcjh tool does not seem to generate
target-specific code and, IMHO, should just be called
"gcjh", instead of (say) "mingw32-gcjh" for a
cross-compiler toolchain.
Sincerely Yours,
Ranjit.
--
Ranjit Mathew Email: rmathew AT hotmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/