Cross Compiling Issues in GCJ 3.3

Mon Jan 20 01:29:00 GMT 2003

>>>>> "Ranjit" == Ranjit Mathew <rmathew@hotmail.com> writes:

Ranjit> BTW, Makefile.am has only one instance of a check for generating
Ranjit> bin_PROGRAMS if NATIVE is defined but Makefile.in gets *two* such
Ranjit> definitions - one with $(EXEEXT), one without. How???
This is the ugliest part of automake (at least 1.4; this may have
changed since then -- it is hard to remember). We handle EXEEXT by
emitting a second definition for _PROGRAMS variables.
Ranjit> It has become more complicated than that - contrary to the
Ranjit> documentation, "with_cross_host" is no longer being passed
Ranjit> to the libjava configure by the top-level Makefile
That sounds like a regression to me. I don't know what, if anything,
can be done about it. Perhaps the change has been documented
somewhere. I haven't really been paying attention to this area; could
you try to find out?
>> 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.

Ranjit> The "gcc/java/Make-lang.in" file defines these as "target
Ranjit> independent" executables and yet applies "program
Ranjit> transformation" to their names before installing, which
Ranjit> prefixes the "mingw32-" to their names. If they are target
Ranjit> independent, why should their names be transformed?
I think this is a bug (opinions may vary). But last time I looked at
it, it looked difficult to fix. I think I brought it up on the gcc
list but didn't get an answer.
Tom