Re: Cross Compiling Issues in GCJ 3.3

[Tom Tromey <tromey at redhat dot com>]

>>>>> "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