[MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[Ranjit Mathew]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

  Java and its libraries have been building for the MinGW
targets since at least GCC 3.3, but they are still enumerated
in noconfigdirs for MinGW targets in the top-level configure
script. Because of this, libgcj is not build for MinGW
even if --enable-languages lists java - an explicit
- --enable-libgcj is needed to overcome this. Recently,
target-boehm-gc was also added to this list (and whereever
else ${libgcj} was listed), exacerbating the problem.

This patch removes this unnecessary enumeration from
configure.in. Regenerating configure using FSF autoconf
2.13 shows that only this line is affected in the generated
script and therefore it should be pretty safe even this
late in the release cycle (it affects *only* MinGW in any
case).

OK for mainline?

Thanks,
Ranjit.

- --
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://rmathew.com/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEhtSrYb1hx2wRS48RAk/nAJ0auMGMwVjo99nBUs6NSmVTBEUxZgCdFWCc
ApNmeUFhEJlDm23shk3qPMI=
=l/EH
-----END PGP SIGNATURE-----

[-- Attachment #2: p1.txt --]
[-- Type: text/plain, Size: 702 bytes --]

Index: ChangeLog
from  Ranjit Mathew  <rmathew@gcc.gnu.org>

	PR target/19970
	* configure.in: Remove target-boehm-gc and ${libgcj} from noconfigdirs
	for MinGW targets.
	* configure: Regenerate.

Index: configure.in
===================================================================
--- configure.in	(revision 114459)
+++ configure.in	(working copy)
@@ -616,7 +616,7 @@ case "${target}" in
     ;;
   i[[3456789]]86-*-mingw32*)
     target_configdirs="$target_configdirs target-mingw"
-    noconfigdirs="$noconfigdirs expect target-libgloss target-boehm-gc ${libgcj}"
+    noconfigdirs="$noconfigdirs expect target-libgloss"
 
     # Can't build gdb for mingw32 if not native.
     case "${host}" in

Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[David Ayers]

Ranjit Mathew schrieb:
> Ranjit Mathew wrote:
> 
>>>  Java and its libraries have been building for the MinGW
>>>targets since at least GCC 3.3, but they are still enumerated
>>>in noconfigdirs for MinGW targets in the top-level configure
>>>script. Because of this, libgcj is not build for MinGW
>>>even if --enable-languages lists java - an explicit
>>>--enable-libgcj is needed to overcome this. Recently,
>>>target-boehm-gc was also added to this list (and whereever
>>>else ${libgcj} was listed), exacerbating the problem.
> 
> 
> The exacerbated problem is that even --enable-libgcj doesn't
> pull in Boehm-GC and neither does --enable-java-gc=boehm.
> 
> The current situation is therefore something of a showstopper
> for Java on MinGW.

I had followed this advice which seemed reasonable:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00886.html

But it seems --enable-libgcj is indeed used to enable java where it
isn't enabled by default where I had the impression that it was used to
--disable-libgcj it where it is.

(see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963 )

I'm happy to post a patch which would remove target-boehm-gc from
noconfigdirs for the various targets for which I've added them, if that
resolves these issues.  (Note that target-boehm-gc will be re-added to
noconfigdirs dirs if it wasn't requested for Objective-C and Java is not
disabled.)

Yet I fail to understand the need for --enable/disable-libgcj if it is
merely being used to enable/disable java.  Why isn't that being done via
language variable?

Cheers,
David

Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[Rainer Orth]

Ranjit Mathew <rmathew@gmail.com> writes:

> Ranjit Mathew wrote:
> >   Java and its libraries have been building for the MinGW
> > targets since at least GCC 3.3, but they are still enumerated
> > in noconfigdirs for MinGW targets in the top-level configure
> > script. Because of this, libgcj is not build for MinGW
> > even if --enable-languages lists java - an explicit
> > --enable-libgcj is needed to overcome this. Recently,
> > target-boehm-gc was also added to this list (and whereever
> > else ${libgcj} was listed), exacerbating the problem.
> 
> The exacerbated problem is that even --enable-libgcj doesn't
> pull in Boehm-GC and neither does --enable-java-gc=boehm.
> 
> The current situation is therefore something of a showstopper
> for Java on MinGW.

The same happens for IRIX 6, cf. PR bootstrap/27963.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[Nathanael Nerode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Ayers wrote:
> Yet I fail to understand the need for --enable/disable-libgcj if it is
> merely being used to enable/disable java.  Why isn't that being done via
> language variable?

Probably historical.  :-)

Perhaps you could work up a patch for the top level which does the
following:

(1) removes --enable/disable-libgcj
(2) changes the list of default languages to not include Java for the
former targets which defaulted to --disable-libgcj, and to include Java
for the other targets.  (While you're at it you could enable Java by
default on MinGW.)
(3) determines whether or not to build the libgcj subdir et al. based on
the presence of Java in the language list


This would simplify the gunk at the toplevel quite a bit.  Can anyone
think of a reason not to do this?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEi0yzRGZ0aC4lkIIRAlGJAJoCNLNDL8+fpXcyUME7wWGdqoh5gACgkv4L
dL/QkQHDOJPCDS8GxHzMT+I=
=+8rk
-----END PGP SIGNATURE-----

Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[David Ayers]

Nathanael Nerode schrieb:
> David Ayers wrote:
> 
>>>Yet I fail to understand the need for --enable/disable-libgcj if it is
>>>merely being used to enable/disable java.  Why isn't that being done via
>>>language variable?
> 
> 
> Probably historical.  :-)
> 
> Perhaps you could work up a patch for the top level which does the
> following:
> 
> (1) removes --enable/disable-libgcj
> (2) changes the list of default languages to not include Java for the
> former targets which defaulted to --disable-libgcj, and to include Java
> for the other targets.  (While you're at it you could enable Java by
> default on MinGW.)
> (3) determines whether or not to build the libgcj subdir et al. based on
> the presence of Java in the language list

Sure, I can work on that.  But I think this would be something that
should be done after the release branch is created (potentially
backported, if it truly turns out to make things a lot easier).

I think for the release branch it seems safer to apply:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00410.html

Then we should decide whether java should be enabled by default for
MinGW on trunk and mainline with the obvious patch first.  (I'm not sure
whether to interpret your suggestion is a pre-approval for enabling Java
by default for MinGW, or whether we need a buy-in from a MinGW
maintainer [I've cc:ed Danny Smith].)

> This would simplify the gunk at the toplevel quite a bit.  Can anyone
> think of a reason not to do this?

I'll take a shot this, but I think we should take the more conservative
route for the release branch for now, and apply the posted patch.

Cheers,
David

Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[Tom Tromey]

>>>>> "Nathanael" == Nathanael Nerode <neroden@fastmail.fm> writes:

>> Yet I fail to understand the need for --enable/disable-libgcj if it is
>> merely being used to enable/disable java.  Why isn't that being done via
>> language variable?

Nathanael> Probably historical.  :-)

Yeah.  I no longer remember the reason for this.

Nathanael> Perhaps you could work up a patch for the top level which
Nathanael> does the following:
[...]

Nathanael> This would simplify the gunk at the toplevel quite a bit.
Nathanael> Can anyone think of a reason not to do this?

It sounds good to me.

Tom

RE: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[Danny Smith]

> -----Original Message-----
> From: David Ayers 
> Sent: Sunday, June 11, 2006 11:57 PM
> 
> Nathanael Nerode schrieb:
> > David Ayers wrote:
> > (2) changes the list of default languages to not include 
> Java for the 
> > former targets which defaulted to --disable-libgcj, and to include 
> > Java for the other targets.  (While you're at it you could 
> enable Java 
> > by default on MinGW.)


> 
> Sure, I can work on that.  But I think this would be 
> something that should be done after the release branch is 
> created (potentially backported, if it truly turns out to 
> make things a lot easier).
> 
> I think for the release branch it seems safer to apply: 
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00410.html

>Then we should decide whether java should be enabled by default
> for MinGW on trunk and mainline with the obvious patch first.
> I'm not sure whether to interpret your suggestion is a pre-approval
> for enabling Java by default for MinGW, or whether we need a
> buy-in from a MinGW maintainer [I've cc:ed Danny Smith].)


I agree that enabling libjava by default for mingw should wait for after branch. Until then I think an explicit  --enable-libgcj should be required.

Since Ranjit's original bug report, I have tried several time to build libgcj natively, in order to verify that it should be enabled by default.  Including libgcj broke bootstrap, not always but often enough for me to have doubts about stability of libgcj builds on mingw.   I can't attempt to test now because the windows box to which I have access  has only 512MB physical memory and that has long been a personal showstopper for native libgcj builds. 

Danny

Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[David Ayers]

Nathanael Nerode schrieb:
> David Ayers wrote:
> 
>>>Yet I fail to understand the need for --enable/disable-libgcj if it is
>>>merely being used to enable/disable java.  Why isn't that being done via
>>>language variable?
> 
> 
> Probably historical.  :-)
> 
> Perhaps you could work up a patch for the top level which does the
> following:
> 
> (1) removes --enable/disable-libgcj
> (2) changes the list of default languages to not include Java for the
> former targets which defaulted to --disable-libgcj, and to include Java
> for the other targets.  (While you're at it you could enable Java by
> default on MinGW.)
> (3) determines whether or not to build the libgcj subdir et al. based on
> the presence of Java in the language list
> 
> 
> This would simplify the gunk at the toplevel quite a bit.  Can anyone
> think of a reason not to do this?

Before I continue working on this for 4.3, I would like to have a signal
from the java maintainers, if they actually agree with this approach in
the light of:

http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00795.html

in which there seems to be a reluctance to make building the runtime
dependant on building the front-end.

Cheers,
David

Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure

[Tom Tromey]

>>>>> "David" == David Ayers <d.ayers@inode.at> writes:

David> Before I continue working on this for 4.3, I would like to have
David> a signal from the java maintainers, if they actually agree with
David> this approach in the light of:
David> http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00795.html

David> in which there seems to be a reluctance to make building the runtime
David> dependant on building the front-end.

We've talked a bit about doing separate builds of libgcj so that we
can release it more quickly.

I think we ought to come to a decision about this now.  In
particular, what option(s), if any, we think we'll need.

Tom