who's been mucking with EXEEXT?

[Jeff Sturm]

On 26 Aug 2002, Adam Megacz wrote:
> 'Fess up.  You broke cross-builds targeting mingw.  The Makefile now
> tries to execute 'gcjh.exe' when host is a unixoid and target is
> mingw/cygwin.  This is wrong.

Hmm... I agree that is wrong, but I don't see how it could've broken
recently:

[jsturm@mars libjava]$ cvs annotate Makefile.am | grep gcjh
Annotations for Makefile.am
***************
1.1          (tromey   07-Apr-99): GCJH = gcjh
1.1          (tromey   07-Apr-99): GCJH =
$(MULTIBUILDTOP)../$(COMPPATH)/gcc/gcjh$(EXEEXT)

The 2nd definition applies to non-canadian crosses.  This section hasn't
changed since the original libgcj import.

Anyway, am I incorrect saying that gcjh is a host utility but EXEEXT
is a target setting?  And even for win32 hosts, $(EXEEXT) need not be
present in this macro to find gcjh?  So perhaps all that's needed is:

2002-08-27  Jeff Sturm  <jsturm@one-point.com>

	* Makefile.am (ZIP, GCJH): Remove $(EXEEXT).

Index: Makefile.am
===================================================================
RCS file: /cvs/gcc/gcc/libjava/Makefile.am,v
retrieving revision 1.239
diff -u -r1.239 Makefile.am
--- Makefile.am	24 Aug 2002 22:46:17 -0000	1.239
+++ Makefile.am	28 Aug 2002 04:05:30 -0000
@@ -57,14 +57,14 @@
 if NULL_TARGET
 ## In this case, gcj is found outside the build tree.  However, zip is
 ## found in the build tree.
-ZIP = $(MULTIBUILDTOP)../$(COMPPATH)/fastjar/jar$(EXEEXT)
+ZIP = $(MULTIBUILDTOP)../$(COMPPATH)/fastjar/jar
 else
 ZIP = jar
 endif
 GCJH = gcjh
 else # CANADIAN
-GCJH = $(MULTIBUILDTOP)../$(COMPPATH)/gcc/gcjh$(EXEEXT)
-ZIP = $(MULTIBUILDTOP)../$(COMPPATH)/fastjar/jar$(EXEEXT)
+GCJH = $(MULTIBUILDTOP)../$(COMPPATH)/gcc/gcjh
+ZIP = $(MULTIBUILDTOP)../$(COMPPATH)/fastjar/jar
 endif # CANADIAN

 ## The compiler with whatever flags we want for both -c and -C