Re: flag day for Solaris portions of config.{guess,sub}

Re: flag day for Solaris portions of config.{guess,sub}

[bkorb]

As someone who was originally confused by the strange transforms,
I'd suggest any changes be towards minimizing differences from the
output from "uname(1)".  In this already mutilated case, history
needs to prevail:

  osrev=solaris`uname -r | sed 's/^5\.//'`

and if "uname -r" stops prefixing its output with that weirdo "5."
thingey, then the version will start being whatever "uname -r"
says it is.

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

bkorb@veritas.com writes:

> As someone who was originally confused by the strange transforms,
> I'd suggest any changes be towards minimizing differences from the
> output from "uname(1)".  In this already mutilated case, history
> needs to prevail:
> 
>   osrev=solaris`uname -r | sed 's/^5\.//'`
> 
> and if "uname -r" stops prefixing its output with that weirdo "5."
> thingey, then the version will start being whatever "uname -r"
> says it is.

But this change would be weirder than anything else suggested so far: you
get solaris5.1 for SunOS 5.5.1/Solaris 2.5.1, and any matching on solaris2*
would be gone.

If we really want to follow uname, than go for sunos`uname -r` which will
remain valid (and recognizable at least by non-newbies) for the forseeable
future.  But again, this gives tons of maintainers absurd maintenance
hazzles for minimal value.

	Rainer

Re: flag day for Solaris portions of config.{guess,sub}

[Bruce Korb]

Rainer Orth wrote:
> 
> > ... In this already mutilated case, history needs to prevail:
> >
> >   osrev=solaris`uname -r | sed 's/^5\.//'`
> >
> > and if "uname -r" stops prefixing its output with that weirdo "5."
> > thingey, then the version will start being whatever "uname -r"
> > says it is.
> 
> But this change would be weirder than anything else suggested so far: you
> get solaris5.1 for SunOS 5.5.1/Solaris 2.5.1, and any matching on solaris2*
> would be gone.

Yep.  Write that off to a typo, sorry:

> >   osrev=solaris`uname -r | sed 's/^5\./2./'`

> If we really want to follow uname, than go for sunos`uname -r` which will
> remain valid (and recognizable at least by non-newbies) for the forseeable
> future.  But again, this gives tons of maintainers absurd maintenance
> hazzles for minimal value.

If "uname -r" stops prefixing the version with "5.", then it has
changed enough for maintainers to take some note.  I think, anyway.  :)

Re: flag day for Solaris portions of config.{guess,sub}

[Wolfgang Bangerth]

Zack Weinberg writes:
>  And you completely ignored the issue of non-autoconf users of 
> config.sub/guess.

Exactly. Just a random note about how some people use config.guess: we have a 
testsuite for our library, which heavily exercises floating point. Since FP 
units vary between processors, we sometimes get results that differ in the 
minor digits of the output, and that's why we store output files for each 
platform, canonicalized by config.guess. I.e., we have directories
  testsuite/results/i686-pc-linux-gnu
  testsuite/results/sparc-sun-solaris2.7
  ...
If you change the canonicalized name of one of these, this would inflict major 
pain on us, since CVS doesn't easily allow to rename directories. I know how 
to fix this, but it involves messing with the CVS archive, and it's not a 
one-line change. 

I consider the proposed change totally useless, and not trivial to work around 
in situations as above.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

flag day for Solaris portions of config.{guess,sub}

[Ben Elliston]

Paul Eggert has been asking over the course of the last year when
config.{guess,sub} will start to correctly identify Solaris version
numbers.  The problem is that config.guess misidentifies Solaris 7, 8,
and 9, and it will probably misidentify Solaris 10 (unless Sun
marketing changes Solaris names again).  For example, on a Solaris 8
box, config.guess outputs "sparc-sun-solaris2.8"; but there never was
and never will be a "Solaris 2.8", as Solaris 2.6 (SunOS 5.6) was
immediately followed by Solaris 7 (SunOS 5.7).

The time to fix this is now long overdue.  Before I do, I want to give
plenty of warning to the GNU packages that comprise the toolchain, as
these are typically most sensitive to the output of config.guess.  Any
objections?  I have documented the change in a new config/NEWS file
that is already committed to subversions.gnu.org.

Ben

Re: flag day for Solaris portions of config.{guess,sub}

[Ben Elliston]

Ben Elliston <bje@wasabisystems.com> writes:

> The time to fix this is now long overdue.

I forgot to mention that config.sub will offer aliases for a lengthy
duration so that users won't be as surprised by this change.

Ben

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> Any objections?

What's the rationale, apart from endorsing Sun's marketing changes?

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

Ben Elliston <bje@wasabisystems.com> writes:

> Paul Eggert has been asking over the course of the last year when
> config.{guess,sub} will start to correctly identify Solaris version
> numbers.  The problem is that config.guess misidentifies Solaris 7, 8,
> and 9, and it will probably misidentify Solaris 10 (unless Sun
> marketing changes Solaris names again).  For example, on a Solaris 8
> box, config.guess outputs "sparc-sun-solaris2.8"; but there never was
> and never will be a "Solaris 2.8", as Solaris 2.6 (SunOS 5.6) was
> immediately followed by Solaris 7 (SunOS 5.7).
> 
> The time to fix this is now long overdue.  Before I do, I want to give
> plenty of warning to the GNU packages that comprise the toolchain, as
> these are typically most sensitive to the output of config.guess.  Any
> objections?  I have documented the change in a new config/NEWS file
> that is already committed to subversions.gnu.org.

I consider this sort of change a maintenance nightmare: suddenly all
packages that could handle all versions of Solaris 2 in the same way
(matching *-*-solaris2*) have to handle *-*-solaris2*, *-*-solaris[789] and
*-*-solaris2.1*.  I see no real reason to follow Sun's marketing nonsense
in this issue, and as you already indicate, there's a `good' change that
Solaris 10 will be called differently again.  All Sun employees are
talking about Solaris Next, e.g., knowing all too well that marketing will
get it's dirty fingers on this issue before FCS.  I've been told that they
were very close to calling Solaris 9 something completely different.

If one really *must* change something for technical correctness, switch to
*-*-sunos5*, which will allways remain correct as has already been
indicated, i.e. whatever they happen to call Solaris 10 by the time it's
released, the O/S will be SunOS 5.10.  But even this sort of change
unnecessarily confuses users and creates a maintenance burden on all users
of config.{guess, sub}.

	Rainer

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

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

> suddenly all packages that could handle all versions of Solaris 2 in
> the same way (matching *-*-solaris2*) have to handle *-*-solaris2*,
> *-*-solaris[789] and *-*-solaris2.1*.

How many programs are actually affected here?

I just checked Emacs, which I thought would care, and it doesn't; it
treats all versions later than Solaris 2.6 with a *-solaris* pattern.
Libtool doesn't seem to care either.  A few programs do care: I just
checked my collection of sources and found GCC, GDB, Kaffe, OpenSSL,
and Tcsh.  But I don't think it's much of a maintenance burden to
update these few examples.  I can propose patches myself for each of
these, if that would help assuage fears about this change.  (If
desirable, these patches could be installed now, before config.guess
changes, since they would work with both the old and the new
config.guess.)


> If one really *must* change something for technical correctness, switch to
> *-*-sunos5*,

Isn't that change even more intrusive?  It would require changing the
handling of Solaris 2.0 through 2.6 as well.

I agree that in retrospect -sunos5* would have been a better name choice.
If the consensus is to switch to -sunos5*, then that's OK with me.
But it'll be less work right now to adopt the solution proposed in
<http://savannah.gnu.org/cgi-bin/viewcvs/config/config/NEWS?rev=HEAD&content-type=text/vnd.viewcvs-markup>.


Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> What's the rationale...?

It's to avoid unnecessary minor barriers to the use of GNU software on
Solaris hosts.  config.guess currently uses incorrect version numbers
for Solaris, and this needlessly confuses new and potential users and
installers of GNU software on Solaris.

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

Paul Eggert writes:

> How many programs are actually affected here?
>
> I just checked Emacs, which I thought would care, and it doesn't; it
> treats all versions later than Solaris 2.6 with a *-solaris* pattern.
> Libtool doesn't seem to care either.  A few programs do care: I just
> checked my collection of sources and found GCC, GDB, Kaffe, OpenSSL,
> and Tcsh.  But I don't think it's much of a maintenance burden to
> update these few examples.  I can propose patches myself for each of
> these, if that would help assuage fears about this change.  (If
> desirable, these patches could be installed now, before config.guess
> changes, since they would work with both the old and the new
> config.guess.)

You've looked at a heavily biased collection: most GNU programs don't care
too much about specific O/S versions.  Many others do: I've just checked
am-utils, ntp, and pidentd, and all of them are affected.  It's true that
it is possible to propose patches for all of them, but getting them
integrated into all affected packages (and I'm very sure much more will pop
up if you broaden your search) is a heavy burden on lots of maintainers for
no other reason than Sun's marketing `correctness'.  I'm usually quite
picky about correct naming myself (evidence the proposed sparcv9 -> sparc64
change in config.guess), but I value compatibility considerably higher than
this.  I consider this one of several completely unnecessary incompatible
interface changes that Jörg Schilling so often complains about in
comp.unix.solaris ;-(

> > If one really *must* change something for technical correctness, switch to
> > *-*-sunos5*,
>
> Isn't that change even more intrusive?  It would require changing the
> handling of Solaris 2.0 through 2.6 as well.

Sure it is, but if you want stay safe from future O/S renaming by Sun
marketing, it's the only reasonable way.  Your proposed change from
*-*-solaris2.7 etc. to *-*-solaris7 etc. will create a massive maintenance
burden now and is likely to do so again in the future should Sun decide
that Solaris 10 (or 11) will be called something different.  Either keeping
the status quo (solaris2.x) or switching to sunos5.x protects you from this
marketing nonesense.

> > What's the rationale...?
>
> It's to avoid unnecessary minor barriers to the use of GNU software on
> Solaris hosts.  config.guess currently uses incorrect version numbers
> for Solaris, and this needlessly confuses new and potential users and
> installers of GNU software on Solaris.

As indicated by what?  I've never seen such a complaint before, and it's
almost never necessary to specify such a configure triplet manually since
it's guessed correctly.

	Rainer

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

Re: flag day for Solaris portions of config.{guess,sub}

[Albert Chin-A-Young]

On Thu, Nov 20, 2003 at 08:14:30PM +0100, Rainer Orth wrote:
> Paul Eggert writes:
> > > What's the rationale...?
> > 
> > It's to avoid unnecessary minor barriers to the use of GNU software on
> > Solaris hosts.  config.guess currently uses incorrect version numbers
> > for Solaris, and this needlessly confuses new and potential users and
> > installers of GNU software on Solaris.
> 
> As indicated by what?  I've never seen such a complaint before, and it's
> almost never necessary to specify such a configure triplet manually since
> it's guessed correctly.

Scripts that admins have that depend on config.guess to determine the
platform name might break. I don't see this change having any value.

-- 
albert chin (china@thewrittenword.com)

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

> Either keeping the status quo (solaris2.x) or switching to sunos5.x
> protects you from this marketing nonesense.

It'd be OK with me to switch to sunos5.x, if that's the consensus.


> > It's to avoid unnecessary minor barriers to the use of GNU software on
> > Solaris hosts.
> 
> As indicated by what?  I've never seen such a complaint before

I was confused myself when the wrong naming convention was originally
introduced.  I recall seeing other instances of confusion on several
occasions.  It's hard to do a google search to find instances of this
(and I suspect most newbies who get confused figure it out eventually,
and don't send email about it), but I just did a quick google search
and found the following messages indicating some degree of confusion,
or a need to explain it, or whatever.  This is the best I can do with
a quick search, but I think the problem is a continuing one for
Solaris and/or GNU novices.

http://mail.gnu.org/archive/html/bug-make/2001-08/msg00023.html
http://mail.python.org/pipermail/python-bugs-list/2002-February/009878.html
http://groups.google.com/groups?selm=yecwv93tve5.fsf%40king.cts.com
http://groups.google.com/groups?selm=39F5B44B.59267146%40webcom.com
http://groups.google.com/groups?selm=200010041042.DAA65166%40king.cts.com


> I've just checked am-utils, ntp, and pidentd, and all of them are
> affected.

No doubt other programs will be affected too.  But these programs are
a relative handful.

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

Paul Eggert writes:

> > I've just checked am-utils, ntp, and pidentd, and all of them are
> > affected.
> 
> No doubt other programs will be affected too.  But these programs are
> a relative handful.

This list came up from the first three that came to mind (and that I
contributed to at some point).  You create work for many maintainers for no
value to them whatsoever, only obscuring the configure scripts with
handling for solaris2.<x>, solaris<x> and some solaris<n> (or whatever)
when Sun comes up with a new name.

A continued burden which removes clarity from those scripts, in exchange
for a little less newby confusion (who will be confused by SunOS 5.x
vs. Solaris 2.x/x anyway).

	Rainer

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

> A continued burden which removes clarity from those scripts,

Using -sunos5* would not remove clarity from scripts, as it's just as
clear as -solaris2*.  And it would not be a continued burden, as it's
just a one-time conversion for a relatively small number of packages.

> in exchange for a little less newby confusion

It is a tradeoff between maintainer convenience and newbie convenience.
The easiest thing for maintainers is to do nothing, and continue to
confuse novices in this minor way.  (After all, we've invented our own
nonstandard jargon that works for us, and if it confuses novices then
that's their problem.  :-)

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

Paul Eggert writes:

> Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> 
> > A continued burden which removes clarity from those scripts,
> 
> Using -sunos5* would not remove clarity from scripts, as it's just as
> clear as -solaris2*.  And it would not be a continued burden, as it's

My comment was referring to the -solaris2.x/-solaris[789]/-solaris<n>
variant, where we are left without a catch-all pattern for Solaris 2.
-sunos5* is certainly ok in this respect, but also a massive change over
dozens or hundreds of packages for no real gain.

> It is a tradeoff between maintainer convenience and newbie convenience.
> The easiest thing for maintainers is to do nothing, and continue to
> confuse novices in this minor way.  (After all, we've invented our own
> nonstandard jargon that works for us, and if it confuses novices then
> that's their problem.  :-)

Exactly: apart from the minor confusion (which is already there by the
SunOS 5 vs. Solaris 2 vs. Solaris 7/8/9/10 mess), no harm is done by
sticking to the established convention of using solaris2* instead of
sunos5*.  The bad choice to use solaris2* instead of sunos5* (where Sun had
already created lots of confusion by re-branding SunOS 4.1.1B to Solaris
1.0) as config.guess output had been made early in the history of Solaris 2, 
and this whole discussion clearly suggest that we stick with that
(admittedly bad) choice since compatibility is considerably more important
than following marketing inventions.

	Rainer

Re: flag day for Solaris portions of config.{guess,sub}

[Richard Stallman]

It seems to me that we should make the change.
Referring to system versions by the same numbers that
the publisher uses is a good idea in general.
It will take a fairly small amount of work to adapt
a bounded set of GNU packages to this change.
So we may as well do it.

Re: flag day for Solaris portions of config.{guess,sub}

[Branko Čibej]

Richard Stallman wrote:

>It seems to me that we should make the change.
>Referring to system versions by the same numbers that
>the publisher uses is a good idea in general.
>It will take a fairly small amount of work to adapt
>a bounded set of GNU packages to this change.
>So we may as well do it.
>  
>
What about the thousands of non-GNU packages that use config.guess?

-- 
Brane ÄŒibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

<brane@xbc.nu> writes:

> What about the thousands of non-GNU packages that use config.guess?

Most of them won't care one way or another, for the same reason that
only a tiny fraction of GNU programs care.

Obviously there are both pros and cons to changing config.guess to use
correct Sun version numbers.  The people who will be hassled by the
correction (namely, a handful of maintainers) are more likely to
complain about it, while the people who will benefit from the
correction (e.g., newbie installers) don't know what's happening and
we won't hear from them here.  (If the American Congress were to vote
on this issue, the handful of special interests would win hands down.
Sigh. :-)

ro didn't favor the proposed change, but suggested that if we change
it, we should standardize on -sunos uniformly, and use e.g., -sunos5.9
rather than -solaris9.  That's fine with me, and in fact it's a bit
cleaner.  It may cause a bit more work since it renames -solaris2.0
through -solaris2.6 too, but these OSes are obsolete as Sun no longer
issues patches for them, so it's not a big deal these days.

Here's a patch to do it that way, if you prefer.


2003-11-24  Paul Eggert  <eggert@twinsun.com>

	Standardize on -sunos* for SunOS versions, rather than using
	-sunos* for older versions and (incorrectly-numbered) -solaris* for
	newer versions.

	* config.guess (sun4H:SunOS:5.*:*, sun4*:SunOS:5.*:*,
	tadpole*:SunOS:5.*:*, i86pc:SunOS:5.*:*, prep*:SunOS:5.*:*):
	Guess -sunosN instead of -solarisM, as we are standardizing
	on -sunos for SunOS hosts.
	* config.sub (i*86sol2, sun4sol2, -solaris*): Likewise.
	(-solaris, -sunos5*): Remove cases.
	(-solaris2, -solaris2.*, -solaris[789], -solaris[789].*,
	-solaris[1-9][0-9]*, -sunos*): New cases.

	* config.guess (sun4*:SunOS:6*:*):
	Remove case: There never will be a "Solaris 3".
	* config.sub (-sunos6*): Likewise.

cvs server: Diffing .
Index: config.guess
===================================================================
RCS file: /cvsroot/config/config/config.guess,v
retrieving revision 1.287
diff -p -u -r1.287 config.guess
--- config.guess	20 Nov 2003 09:20:24 -0000	1.287
+++ config.guess	24 Nov 2003 06:24:46 -0000
@@ -338,19 +338,17 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
 	    sparc) echo sparc-icl-nx7 && exit 0 ;;
 	esac ;;
     sun4H:SunOS:5.*:*)
-	echo sparc-hal-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	echo sparc-hal-sunos${UNAME_RELEASE}
 	exit 0 ;;
+    # Previous versions of config.guess incorrectly identified Solaris 7
+    # as solaris2.7, and similarly for Solaris 8 and Solaris 9.
+    # config.guess now identifies these OSes by SunOS version, e.g.,
+    # sparc-sun-sunos5.9 instead of the incorrect sparc-sun-solaris2.9.
     sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
-	echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	echo sparc-sun-sunos${UNAME_RELEASE}
 	exit 0 ;;
     i86pc:SunOS:5.*:*)
-	echo i386-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
-	exit 0 ;;
-    sun4*:SunOS:6*:*)
-	# According to config.sub, this is the proper way to canonicalize
-	# SunOS6.  Hard to guess exactly what SunOS6 will be like, but
-	# it's likely to be more like Solaris than SunOS4.
-	echo sparc-sun-solaris3`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	echo i386-pc-sunos${UNAME_RELEASE}
 	exit 0 ;;
     sun4*:SunOS:*:*)
 	case "`/usr/bin/arch -k`" in
@@ -807,7 +805,7 @@ EOF
 	echo powerpcle-unknown-cygwin
 	exit 0 ;;
     prep*:SunOS:5.*:*)
-	echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	echo powerpcle-unknown-sunos${UNAME_RELEASE}
 	exit 0 ;;
     *:GNU:*:*)
 	# the GNU system
Index: config.sub
===================================================================
RCS file: /cvsroot/config/config/config.sub,v
retrieving revision 1.297
diff -p -u -r1.297 config.sub
--- config.sub	20 Nov 2003 09:20:24 -0000	1.297
+++ config.sub	24 Nov 2003 06:24:48 -0000
@@ -593,7 +593,7 @@ case $basic_machine in
 		;;
 	i*86sol2)
 		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
-		os=-solaris2
+		os=-sunos5
 		;;
 	i386mach)
 		basic_machine=i386-mach
@@ -916,7 +916,7 @@ case $basic_machine in
 		;;
 	sun4sol2)
 		basic_machine=sparc-sun
-		os=-solaris2
+		os=-sunos5
 		;;
 	sun3 | sun3-*)
 		basic_machine=m68k-sun
@@ -1113,12 +1113,17 @@ then
 case $os in
         # First match some system type aliases
         # that might get confused with valid system types.
-	# -solaris* is a basic system type, with this one exception.
 	-solaris1 | -solaris1.*)
 		os=`echo $os | sed -e 's|solaris1|sunos4|'`
 		;;
-	-solaris)
-		os=-solaris2
+	-solaris2 | -solaris2.*)
+		os=`echo "$os" | sed -e 's|solaris2|sunos5|'`
+		;;
+	-solaris[789] | -solaris[789].* | -solaris[1-9][0-9]*)
+		os=`echo "$os" | sed -e 's|solaris|sunos5.|'`
+		;;
+	-solaris*)
+		os=-sunos5
 		;;
 	-svr4*)
 		os=-sysv4
@@ -1135,7 +1140,7 @@ case $os in
 	# -sysv* is not here because it comes later, after sysvr4.
 	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
 	      | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[34]*\
-	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
+	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -sunos* | -sym* \
 	      | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \
 	      | -aos* \
 	      | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \
@@ -1181,12 +1186,6 @@ case $os in
 		;;
 	-linux*)
 		os=`echo $os | sed -e 's|linux|linux-gnu|'`
-		;;
-	-sunos5*)
-		os=`echo $os | sed -e 's|sunos5|solaris2|'`
-		;;
-	-sunos6*)
-		os=`echo $os | sed -e 's|sunos6|solaris3|'`
 		;;
 	-opened*)
 		os=-openedition

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> Most of them won't care one way or another, for the same reason that
> only a tiny fraction of GNU programs care.

Do you have any numbers backing this statement?

> Obviously there are both pros and cons to changing config.guess to use
> correct Sun version numbers.  The people who will be hassled by the
> correction (namely, a handful of maintainers) are more likely to
> complain about it, while the people who will benefit from the
> correction (e.g., newbie installers) don't know what's happening and
> we won't hear from them here.

I tend to think that people compiling sources on Solaris boxes are not 
newbies.

> (If the American Congress were to vote on this issue, the handful of
> special interests would win hands down. Sigh. :-)

I'd rather say: classical tension between experts in a field and the 
non-expert public.  The experts' opinion may sometimes be valuable :-)

> ro didn't favor the proposed change, but suggested that if we change
> it, we should standardize on -sunos uniformly, and use e.g., -sunos5.9
> rather than -solaris9.  That's fine with me, and in fact it's a bit
> cleaner.

But is only marginally clearer for so-called newbies.  And in the GCC tree, 
for example, all SunOS-specific files are named sol2*.

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> > Most of them won't care one way or another, for the same reason that
> > only a tiny fraction of GNU programs care.
> 
> Do you have any numbers backing this statement?

Only the numbers mentioned on this thread.  I think about 10 programs
have been mentioned as being affected by this change, most of which
are not GNU programs.

The vast majority of programs don't care about this stuff, as far as I
can tell.


> I tend to think that people compiling sources on Solaris boxes are not 
> newbies.

Hmm, well, I currently have 60 students compiling sources on Solaris
boxes.  They're all Solaris newbies.

Just one data point, I know, but there are still a reasonable number
of Solaris newbies out there.  (I've asked the school to switch to
GNU/Linux; but for various reasons it probably won't happen any time
soon.)


> In the GCC tree, for example, all SunOS-specific files are named
> sol2*.

Not all SunOS-specific files in GCC are named sol2*.  Only files
specific to SunOS 5.0 and later have that name.  Other files have
sunos4* names and suchlike.  This is an example of naming confusion
within GCC, but I don't propose to change all that right now.  (One
step at a time.)

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> Only the numbers mentioned on this thread.  I think about 10 programs
> have been mentioned as being affected by this change, most of which
> are not GNU programs.

Are you sure they are the only ones?

> Hmm, well, I currently have 60 students compiling sources on Solaris
> boxes.  They're all Solaris newbies.

Did they run into the 'minor barrier'?

> Not all SunOS-specific files in GCC are named sol2*. Only files
> specific to SunOS 5.0 and later have that name.  Other files have
> sunos4* names and suchlike.

I don't see any in the mainline sources.

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> > Only the numbers mentioned on this thread.  I think about 10 programs
> > have been mentioned as being affected by this change, most of which
> > are not GNU programs.
> 
> Are you sure they are the only ones?

No: on the contrary, I expect that there are a few more.  However,
it's still the case that only a very small number of programs are
affected, compared to the hundreds (or thousands?) of programs that
use config.guess and config.sub.


> > Hmm, well, I currently have 60 students compiling sources on Solaris
> > boxes.  They're all Solaris newbies.
> 
> Did they run into the 'minor barrier'?

Not this academic quarter; they're using Python, which isn't affected.
However, in past quarters I have had them build GCC, so they were
affected.  (Others in my department think I'm crazy to have
undergraduates look inside GCC; they prefer to teach with toy
compilers.  But I digress....)


> > Not all SunOS-specific files in GCC are named sol2*. Only files
> > specific to SunOS 5.0 and later have that name.  Other files have
> > sunos4* names and suchlike.
> 
> I don't see any in the mainline sources.

Ah, OK, you must be referring to the current CVS, which has ripped out
support for SunOS 4 and earlier.  I was referring to the latest stable
version, GCC 3.3.2, which still has some files with sunos4* names.
But at any rate this discrepancy is a minor one, as I'm not proposing
to rename all those files right now.

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> No: on the contrary, I expect that there are a few more.  However,
> it's still the case that only a very small number of programs are
> affected, compared to the hundreds (or thousands?) of programs that
> use config.guess and config.sub.

Forgive my insistence, but without real numbers one could still argue that 
this is only a piece of wishful thinking.

Moreover, I think you didn't really take into account the additional burden 
this would place on the shoulders of maintainers.  I can speak for the GCC 
side: Solaris is a pain to support, period.  You can't simply say: upgrade 
binutils, don't use this Bash version and so on.  No, you have to cope
with all the glitches of the shells, the assembler, the linker, the headers, 
the libraries, etc.  So please, please, please, don't gratuitously add 
another layer of difficulties on top of this mess.

> Not this academic quarter; they're using Python, which isn't affected.
> However, in past quarters I have had them build GCC, so they were
> affected.

But were they really affected? I mean, beyond scratching their head for 2 
minutes after seeing the triplet.

> Ah, OK, you must be referring to the current CVS, which has ripped out
> support for SunOS 4 and earlier.  I was referring to the latest stable
> version, GCC 3.3.2, which still has some files with sunos4* names.

Yes.  Only SunOS 5.x will be supported in GCC 3.4.

> But at any rate this discrepancy is a minor one, as I'm not proposing
> to rename all those files right now.

It was just to point out that it would IMHO be inconsistent to get rid of the 
Solaris moniker, now that GCC only supports Solaris.

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> without real numbers one could still argue that this is only a piece
> of wishful thinking.

It might be helpful to have more numbers, but I don't think they would
affect the conclusion that only a tiny fraction of programs are
affected, and the fixes will be relatively easy.

> I think you didn't really take into account the additional burden
> this would place on the shoulders of maintainers.  I can speak for
> the GCC side: Solaris is a pain to support, period.

Yes, I understand that.  I occasionally have helped with GCC support
on Solaris.  I have volunteered to compose a patch for GCC, if that
would help reassure you.

> > However, in past quarters I have had them build GCC, so they were
> > affected.
> 
> But were they really affected? I mean, beyond scratching their head for 2 
> minutes after seeing the triplet.

2 minutes times 90 students is three hours.  And that's just one class
in one quarter at one university.  After a while it starts to add up.
We want to encourage newbies, not confuse them.

> it would IMHO be inconsistent to get rid of the Solaris moniker, now
> that GCC only supports Solaris.

A more drastic change to GCC's support for Solaris/SunOS, that changes
most instances of 'Solaris' to 'SunOS', would also work (though it'd
take a bit more time to write).  If you'd prefer such a solution I
could propose one along those lines instead.  (Obviously I shouldn't
bother doing any of this unless config.guess/config.sub are changed.)

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> 2 minutes times 90 students is three hours.  And that's just one class
> in one quarter at one university.  After a while it starts to add up.

Weird calculation.  It's still 2 minutes per brain.

> A more drastic change to GCC's support for Solaris/SunOS, that changes
> most instances of 'Solaris' to 'SunOS', would also work (though it'd
> take a bit more time to write).  If you'd prefer such a solution I
> could propose one along those lines instead.  (Obviously I shouldn't
> bother doing any of this unless config.guess/config.sub are changed.)

Oh! no, I'd strongly prefer keeping the current situation.  And pointing to 
the aforementioned FAQ instead.

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Ben Elliston]

Paul Eggert <eggert@CS.UCLA.EDU> writes:

> > But were they really affected? I mean, beyond scratching their head for 2 
> > minutes after seeing the triplet.
> 
> 2 minutes times 90 students is three hours.  And that's just one
> class in one quarter at one university.  After a while it starts to
> add up.  We want to encourage newbies, not confuse them.

Yes, but the job is perfectly parallelised :-)

My opinion (if it matters) is that we should choose a triplet that
insulates us from marketing types at Sun.  sunos5.x seems like a
reasonable choice, but I understand the the change is going to be
really problematic.

Please keep in mind that I know of system administrators who use
config.guess to help set up paths when users log in.  Thus, they have
/usr/local/i686-pc-linux-gnu/ etc. and a change to config.guess'
output will cause them a bit of grief.

Ben

Re: flag day for Solaris portions of config.{guess,sub}

[Russ Allbery]

Ben Elliston <bje@wasabisystems.com> writes:

> My opinion (if it matters) is that we should choose a triplet that
> insulates us from marketing types at Sun.  sunos5.x seems like a
> reasonable choice, but I understand the the change is going to be really
> problematic.

While this sounds like a good idea to those of us deeply in the know and
familiar with the past ten years of Sun operating system history and
marketing idiocies, I think the average newcomer, who is mystified by
uname output, is going to be really confused by sunos5.x.  uname output is
pretty much the only place that's used that the average Solaris user would
see it, and the term "SunOS" is used in the literature and in on-line
discussion pretty much exclusively to refer to SunOS 4.x.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: flag day for Solaris portions of config.{guess,sub}

[Richard Stallman]

    >It seems to me that we should make the change.
    >Referring to system versions by the same numbers that
    >the publisher uses is a good idea in general.
    >It will take a fairly small amount of work to adapt
    >a bounded set of GNU packages to this change.
    >So we may as well do it.
    >  
    >
    What about the thousands of non-GNU packages that use config.guess?

It's the same basic idea.  We never made a commitment to avoid
ever having an incompatible change.

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Richard Stallman <rms@gnu.org> writes:

>     >It seems to me that we should make the change.
>     >Referring to system versions by the same numbers that
>     >the publisher uses is a good idea in general.
>     >It will take a fairly small amount of work to adapt
>     >a bounded set of GNU packages to this change.
>     >So we may as well do it.
>     >  
>     >
>     What about the thousands of non-GNU packages that use config.guess?
>
> It's the same basic idea.  We never made a commitment to avoid
> ever having an incompatible change.

I think there's an expectation, though, since incompatible changes
have not happened before (at least, I cannot think of any previous
incident).  I am with Eric on this: config.guess should not change
its output in an incompatible fashion.  Ever.

config.sub should certainly recognize -solaris7+ as equivalent to
-solaris2.7+.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> It's to avoid unnecessary minor barriers to the use of GNU software on
> Solaris hosts.  config.guess currently uses incorrect version numbers
> for Solaris, and this needlessly confuses new and potential users and
> installers of GNU software on Solaris.

What's the point in exchanging a minor barrier for a major maintainance 
problem?

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

Eric Botcazou writes:

> What's the point in exchanging a minor barrier for a major maintainance 
> problem?

Exactly: all messages Paul came up with were from users wondering about the
discrepancy between their knowledge of the O/S version and the config.guess
output.  The same kind of confusion comes up regularly between SunOS 5.x
and Solaris 2.x/Solaris x, and is resolved as soon as it is explained
(usually by pointing people at the Solaris 2 FAQ).

In all cases, the guess achieved exactly what was desired, no user had
tried to specify e.g. sparc-sun-solaris8 (which is unnecessary except in
the most extraordinary circumstances) and failed.  So what we have works
perfectly well and will continue to do so, while a change is only of
cosmetic value (and the *-*-solaris[789], *-*-solaris1? route is at the
continued mercy of Sun marketing droids).

This is a sure way to anger lots of maintainers for no obvious value.

	Rainer

Re: flag day for Solaris portions of config.{guess,sub}

[Phil Edwards]

On Thu, Nov 20, 2003 at 10:14:47PM +0100, Rainer Orth wrote:
> Eric Botcazou writes:
> 
> > What's the point in exchanging a minor barrier for a major maintainance 
> > problem?
> 
> Exactly: all messages Paul came up with were from users wondering about the
> discrepancy between their knowledge of the O/S version and the config.guess
> output.  The same kind of confusion comes up regularly between SunOS 5.x
> and Solaris 2.x/Solaris x, and is resolved as soon as it is explained
> (usually by pointing people at the Solaris 2 FAQ).

As a longtime user and administrator of Solaris boxes, I strongly agree.
The weirdness is a complete marketing tactic with little technical merit,
and is easily understood by pointing new users at Casper Dik's Solaris 2 FAQ.

This change is unneeded, will create confusion, and gets us no benefit in
exchange for even more work.  Increasing the maintanence hassle for Free
Software authors is hardly a solution to new user's confusion.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan

Re: flag day for Solaris portions of config.{guess,sub}

[tm_gccmail]

On 20 Nov 2003, Ben Elliston wrote:

> Paul Eggert has been asking over the course of the last year when
> config.{guess,sub} will start to correctly identify Solaris version
> numbers.  The problem is that config.guess misidentifies Solaris 7, 8,
> and 9, and it will probably misidentify Solaris 10 (unless Sun
> marketing changes Solaris names again).  For example, on a Solaris 8
> box, config.guess outputs "sparc-sun-solaris2.8"; but there never was
> and never will be a "Solaris 2.8", as Solaris 2.6 (SunOS 5.6) was
> immediately followed by Solaris 7 (SunOS 5.7).

Doesn't uname identify the OS as "SunOS 5.x" ?

If so, I don't see a real reason for this change.


Toshi

Re: flag day for Solaris portions of config.{guess,sub}

[Joe Buck]

On Fri, Nov 21, 2003 at 01:28:13PM -0800, tm_gccmail@kloo.net wrote:
> Doesn't uname identify the OS as "SunOS 5.x" ?

Yes, for Solaris 8 we get, for example,

SunOS capulet 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-4

However, Sun has never used "Solaris 2.8" to identify such systems.

> If so, I don't see a real reason for this change.

I think that we should just document the current behavior and move on.
It can be confusing, but there are higher priority issues.

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Ben Elliston <bje@wasabisystems.com> writes:

> Paul Eggert has been asking over the course of the last year when
> config.{guess,sub} will start to correctly identify Solaris version
> numbers.  The problem is that config.guess misidentifies Solaris 7, 8,
> and 9, and it will probably misidentify Solaris 10 (unless Sun
> marketing changes Solaris names again).  For example, on a Solaris 8
> box, config.guess outputs "sparc-sun-solaris2.8"; but there never was
> and never will be a "Solaris 2.8", as Solaris 2.6 (SunOS 5.6) was
> immediately followed by Solaris 7 (SunOS 5.7).

I'm reiterating what I said way downthread in a more prominent
location because (a) it is buried, and (b) having reflected for 24
hours I now feel much more strongly about the issue.

THE OUTPUT OF CONFIG.GUESS MUST NOT EVER CHANGE.
EVEN IF IT IS WRONG.

It is, however, perfectly fine and in fact desirable for config.sub to
recognize sparc-solaris7 as equivalent to sparc-sun-solaris2.7.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

"Zack Weinberg" <zack@codesourcery.com> writes:

> THE OUTPUT OF CONFIG.GUESS MUST NOT EVER CHANGE.
> EVEN IF IT IS WRONG.

It isn't reasonable to insist on this as an absolute policy.  If this
policy were strictly adhered to, most of the changes to config.guess
would be disallowed, as config.guess typically outputs something wrong
on unusual hosts.

People make mistakes.  Systems change.  The output of config.guess has
changed in the past, and it will change in the future.  The very name
"config.guess" suggests that its output should not be considered to be
unchanging truth.

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Paul Eggert <eggert@CS.UCLA.EDU> writes:

> "Zack Weinberg" <zack@codesourcery.com> writes:
>
>> THE OUTPUT OF CONFIG.GUESS MUST NOT EVER CHANGE.
>> EVEN IF IT IS WRONG.
>
> It isn't reasonable to insist on this as an absolute policy.  If this
> policy were strictly adhered to, most of the changes to config.guess
> would be disallowed, as config.guess typically outputs something wrong
> on unusual hosts.

Possibly I should have phrased it differently.  Referring only to
config.guess gives a misleading impression.  This isn't about bugs in
config.guess/config.sub (which I limit to "conflates two different
systems" and "prints something that doesn't have the form of a
canonical system name").  This is about canonical system names, which
must be stable even if the stable name isn't ideal.

Once a canonical name has been chosen for a given operating system,
that canonical name must not ever change.

Once a pattern of canonical names has been chosen for a given family
of operating systems, that pattern must not ever change.

Do otherwise and you ruin the utility of canonical system names; we
might as well all hand-parse uname -a output.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

"Zack Weinberg" <zack@codesourcery.com> writes:

> Once a pattern of canonical names has been chosen for a given family
> of operating systems, that pattern must not ever change.

That's still too strong.  Changing canonical names is not something
one wants to do lightly of course, but it's not unprecedented.  We
have changed the output of config.guess in the past, notably for
GNU/Linux.

That being said, I'm sympathetic to the design principle you're
advocating.  Ironically, this whole problem occurred because we didn't
follow that principle: we changed the pattern of canonical names for
part of the SunOS family of operating systems from -sunos* to
-solaris*.  My most recent proposal switches back to -sunos*
uniformly, thus adhering to your design principle even more strongly
than the current config.guess does.


> Do otherwise and you ruin the utility of canonical system names

No, the utility is still there.  config.guess is a registry for
canonical system names, much as ISO 639 is a registry for 2-letter
language codes and ISO 3166 is a registry for 2-letter country codes,
All other things being equal we shouldn't change names in a registry.
But those registries occasionally change too (e.g., ISO 639 changed
Hebrew from "iw" to "he", and this year ISO 3166 changed Serbia &
Montenegro from "yu" to "cs").  This is a pain for such widely-used
standards, but sometimes the advantages of the change outweigh the
disadvantages.  Similarly for config.guess.

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Paul Eggert <eggert@CS.UCLA.EDU> writes:

> "Zack Weinberg" <zack@codesourcery.com> writes:
>
>> Once a pattern of canonical names has been chosen for a given family
>> of operating systems, that pattern must not ever change.
>
> That's still too strong.  Changing canonical names is not something
> one wants to do lightly of course, but it's not unprecedented.  We
> have changed the output of config.guess in the past, notably for
> GNU/Linux.

I would argue that every last one of those changes was a mistake, but
a mistake that cannot now be rectified.

> That being said, I'm sympathetic to the design principle you're
> advocating.  Ironically, this whole problem occurred because we didn't
> follow that principle: we changed the pattern of canonical names for
> part of the SunOS family of operating systems from -sunos* to
> -solaris*.

Again, this was a mistake, which *cannot now be rectified*.

Changing it again would be *worse* than the original change was - the
original change happened when solaris2 was still a new thing, not
widely used, and (critically) CPU-sun-solaris2.x / CPU-sun-sunos5.x
patterns did not appear in a large number of autoconf scripts.

My point is really that you and others advocating the change seem to
underestimate the disruption involved by orders of magnitude.  I think
it's roughly comparable to the disruption involved in the switch from
autoconf 2.13 to autoconf 2.5x -- every last configure script on the
planet is going to have to be audited for problems, and possibly
modified.

And configure scripts aren't the only things that use config.guess/
config.sub.  Consider FTP archives and automatic programs that
retrieve files from those archives.  Consider system administrators
using cfengine to manage large heterogeneous networks.  Consider old
backup tapes labelled and formatted according to canonical system name.

Is smoothing out a minor irregularity of naming convention really
worth all this disruption?

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

"Zack Weinberg" <zack@codesourcery.com> writes:

> I think it's roughly comparable to the disruption involved in the
> switch from autoconf 2.13 to autoconf 2.5x -- every last configure
> script on the planet is going to have to be audited for problems,

This overstates the amount of work that will need to be done, as the
vast majority of configure scripts will not be affected by this change,
whereas the switch from Autoconf 2.13 to 2.5x required changes to most
configure.in files.


I sense that we're not making much progress in the discussion any more.
Ben, what's your thought on this matter now?  Are you still inclined
to make the change, or would you rather fork config.guess and
config.sub, or look for some other compromise, or what?

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Paul Eggert <eggert@CS.UCLA.EDU> writes:

> "Zack Weinberg" <zack@codesourcery.com> writes:
>
>> I think it's roughly comparable to the disruption involved in the
>> switch from autoconf 2.13 to autoconf 2.5x -- every last configure
>> script on the planet is going to have to be audited for problems,
>
> This overstates the amount of work that will need to be done, as the
> vast majority of configure scripts will not be affected by this change,
> whereas the switch from Autoconf 2.13 to 2.5x required changes to most
> configure.in files.

The burden is on you to prove that - in the absence of evidence we
must assume that most or all configure scripts *will* have to be
modified; certainly they will all have to be *examined*, which is a
nontrivial amount of work in itself.  And you completely ignored the
issue of non-autoconf users of config.sub/guess.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Ben Elliston]

"Zack Weinberg" <zack@codesourcery.com> writes:

> > This overstates the amount of work that will need to be done, as the
> > vast majority of configure scripts will not be affected by this change,
> > whereas the switch from Autoconf 2.13 to 2.5x required changes to most
> > configure.in files.
> 
> The burden is on you to prove that - in the absence of evidence we
> must assume that most or all configure scripts *will* have to be
> modified; certainly they will all have to be *examined*, which is a
> nontrivial amount of work in itself.  And you completely ignored the
> issue of non-autoconf users of config.sub/guess.

Rather than hypothesise, I took a look at the binutils and gcc trees
to get a handle on how frequently configure.in inspects host/target
triplets for "solaris".  The results are not that surprising.

src/rda/unix/configure.in:  *solaris*)
src/rda/unix/configure.in:    TARGET_MODULES="solaris-target.o dummy-target.o" 
src/rda/unix/configure.in:  *solaris*)
src/expect/configure.in:  *-*-solaris*)		stty_reads_stdout=0 ;;
src/expect/configure.in:solaris=0
src/expect/configure.in:  *-*-solaris*)		solaris=1;;
src/expect/configure.in:if test $solaris -eq 1 ; then
src/gas/configure.in:      i386-*-solaris*)			fmt=elf ;;
src/gas/configure.in:      ppc-*-solaris*)			fmt=elf
src/gas/configure.in:      sparc-*-solaris*)			fmt=elf ;;
src/gas/configure.in:      *-*-elf | *-*-sysv4* | *-*-solaris*) fmt=elf dev=yes ;;
src/gdb/gdbtk/plugins/configure.in:# Only supported/tested on linux, solaris, cygwin
src/gdb/gdbtk/plugins/configure.in:  *solaris*) ;;
src/gdb/configure.in:  solaris2.[[78]])
src/gdb/configure.in:  *-*-solaris2.[[678]])
src/gdb/configure.in:   solaris*)
src/blt/configure.in:  *-solaris2*)
src/sid/component/audio/configure.in:*-solaris*)
src/sim/configure.in:  powerpc*-*-eabi* | powerpc*-*-solaris* | powerpc*-*-sysv4* | \
src/configure.in:  i[[3456789]]86-*-solaris2*)
src/configure.in:  powerpcle-*-solaris*)
src/configure.in:  sparc-*-solaris* | sparc64-*-solaris* | sparcv9-*-solaris*)
src/configure.in:  i[[3456789]]86-*-solaris2*)
src/configure.in:  *-*-solaris2*)
src/configure.in:    host_makefile_frag="config/mh-solaris"
src/configure.in:  sparc-sun-solaris2*)
gcc-mainline/gcc/configure.in:  single | solaris | vxworks | win32 )
gcc-mainline/boehm-gc/configure.in:     *-*-solaris*)
gcc-mainline/boehm-gc/configure.in: decosf1 | irix | mach | os2 | solaris | dce | vxworks)
gcc-mainline/boehm-gc/configure.in: i?86-*-solaris2.[[89]] | i?86-*-solaris2.1?)
gcc-mainline/boehm-gc/configure.in: sparc-sun-solaris2.3)
gcc-mainline/boehm-gc/configure.in: sparc-sun-solaris2.*)
gcc-mainline/boehm-gc/configure.in: sparc-sun-solaris2*|*aix*)
gcc-mainline/libjava/configure.in: decosf1 | irix | mach | os2 | solaris | dce | vxworks)
gcc-mainline/libjava/configure.in: sparc*-sun-solaris*)
gcc-mainline/libffi/configure.in:i*86-*-solaris*) TARGET=X86; TARGETDIR=x86;;
gcc-mainline/configure.in:  i[[3456789]]86-*-solaris2*)
gcc-mainline/configure.in:  powerpcle-*-solaris*)
gcc-mainline/configure.in:  sparc-*-solaris* | sparc64-*-solaris* | sparcv9-*-solaris*)
gcc-mainline/configure.in:  i[[3456789]]86-*-solaris2*)
gcc-mainline/configure.in:  *-*-solaris2*)
gcc-mainline/configure.in:    host_makefile_frag="config/mh-solaris"
gcc-mainline/configure.in:  sparc-sun-solaris2*)

Re: flag day for Solaris portions of config.{guess,sub}

[Richard Stallman]

    > This overstates the amount of work that will need to be done, as the
    > vast majority of configure scripts will not be affected by this change,
    > whereas the switch from Autoconf 2.13 to 2.5x required changes to most
    > configure.in files.

    The burden is on you to prove that - in the absence of evidence we
    must assume that most or all configure scripts *will* have to be
    modified;

Don't we know that most programs that use Autoconf don't actually look
at the configuration name at all?

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Richard Stallman <rms@gnu.org> writes:

>     > This overstates the amount of work that will need to be done, as the
>     > vast majority of configure scripts will not be affected by this change,
>     > whereas the switch from Autoconf 2.13 to 2.5x required changes to most
>     > configure.in files.
>
>     The burden is on you to prove that - in the absence of evidence we
>     must assume that most or all configure scripts *will* have to be
>     modified;
>
> Don't we know that most programs that use Autoconf don't actually look
> at the configuration name at all?

Paul Eggert already presented evidence that roughly 10% of a sample of
configure.in scripts not only look at the configuration name, but
match it against patterns containing the string "solaris" or "sunos".
To my mind that is enough to rule out the proposed change as too costly.

And, for the third time, Autoconf is not the only user of
config.guess/config.sub.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Arnaud Charlet]

> Paul Eggert already presented evidence that roughly 10% of a sample of
> configure.in scripts not only look at the configuration name, but
> match it against patterns containing the string "solaris" or "sunos".

I don't find this surprising. I would also not be surprised if the vast
majority actually match against "solaris*", which would be just fine.

Arno

Re: flag day for Solaris portions of config.{guess,sub}

[Richard Stallman]

    > Don't we know that most programs that use Autoconf don't actually look
    > at the configuration name at all?

    Paul Eggert already presented evidence that roughly 10% of a sample of
    configure.in scripts not only look at the configuration name, but
    match it against patterns containing the string "solaris" or "sunos".
    To my mind that is enough to rule out the proposed change as too costly.

I'm surprised it is so many.  As someone pointed out, the real extent of
the problem depends on how many of them check the version number as well
as the name.  It should be pretty easy to measure that too.

    And, for the third time, Autoconf is not the only user of
    config.guess/config.sub.

The point is that most programs nowadays use Autoconf, so other uses are
few.

Re: flag day for Solaris portions of config.{guess,sub}

[Branko Čibej]

Richard Stallman wrote:

>The point is that most programs nowadays use Autoconf, so other uses are
>few.
>  
>
Sorry to barge in again, but config.guess is used by lots of things
besides programs that use Autoconf; e.g., various sysadmin scripts,
testing and compilation frameworks, etc. etc., where Autoconf is
inappropriate but config.guess is immensely useful. I've written many
such tools myself, and I'd even venture to guess that the numer of such
uses is on the same order as the number of Autoconf uses.

Config.guess is not just a utility for Autoconf; it's a standalone tool,
and any changes made to it should be evaluated in that light. Please
don't make incompatible changes without a very good reason.



"A foolish consistency is the hobgoblin of little minds." --Emerson

-- 
Brane ÄŒibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

Re: flag day for Solaris portions of config.{guess,sub}

[Richard Stallman]

    >The point is that most programs nowadays use Autoconf, so other uses are
    >few.
    >  
    >
    Sorry to barge in again, but config.guess is used by lots of things
    besides programs that use Autoconf; e.g., various sysadmin scripts,
    testing and compilation frameworks, etc. etc., where Autoconf is
    inappropriate but config.guess is immensely useful.

Are you talking about configure scripts that don't use Autoconf?
Or something else entirely?

    Config.guess is not just a utility for Autoconf;

We are miscommunicating; you're arguing against something that is not what
I said.  config.guess is not "a utility for Autoconf".  It's a utility for
configure scripts.  When we developed the configure spec, there was no
such thing as Autoconf.

When Autoconf was developed, it made it possible to write configure scripts
so that they don't need to care about the name of the system.  So
config.guess, and configuration names, are less important than they were in
the past.  Some programs such as GDB still need to check them, but most new
programs rely on Autoconf for the whole job.  At least I think that's the
case for configure scripts.

Are you saying that config.guess is widely used outside of configure
scripts?

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Richard Stallman <rms@gnu.org> writes:

>
> Are you saying that config.guess is widely used outside of configure
> scripts?

Yes.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Joe Buck]

On Fri, Dec 05, 2003 at 09:53:29AM -0800, Zack Weinberg wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> >
> > Are you saying that config.guess is widely used outside of configure
> > scripts?
> 
> Yes.

config.guess is used in a number of places to generate the canonical name
for the type of system that the user is running on.

As an example of such use, consider GCC's test_summary script.  This
script processes the results of a dejagnu test run and mails in a report.
GCC testers use this script regularly so that regressions can be tracked.
These reports go to gcc-testresults@gcc.gnu.org and are archived on the web.
It uses config.guess to fill in the type of system for which tests are
being run.

That said, for many uses of the output of config.guess, a change would not
cause significant harm.  This is especially true for source distributions
that contain their own copy of config.guess: the distribution will generally
be consistent with the copy of config.guess that it contains.


> zw

-- 
Q. What's more of a headache than a bug in a compiler.
A. Bugs in six compilers.  -- Mark Johnson

Re: flag day for Solaris portions of config.{guess,sub}

[Nix]

On Fri, 5 Dec 2003, Joe Buck uttered the following:
> On Fri, Dec 05, 2003 at 09:53:29AM -0800, Zack Weinberg wrote:
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> >
>> > Are you saying that config.guess is widely used outside of configure
>> > scripts?
>> 
>> Yes.
> 
> config.guess is used in a number of places to generate the canonical name
> for the type of system that the user is running on.
> 
> As an example of such use, consider GCC's test_summary script.

Have another random example:

The repository of (compiled) free software I habitually maintain at
every workplace I've ever been in so far has paths for all binaries
which contain the canonical name of the system they run on. Because
these paths are compiled into a number of those binaries, they can't
change safely without fairly large-scale recompilation.

(Thankfully, the filesystem supports symlinks, so I can work around
this: but it'll still be confusing for users who look inside the
appropriate directory and wonder why sparc-sun-solaris2.8 is a symlink
to sparc-sun-sunos5.8... pretty much the same `minor barrier' as was
originally referred to.)

> That said, for many uses of the output of config.guess, a change would not
> cause significant harm.

Agreed.

>                          This is especially true for source distributions
> that contain their own copy of config.guess: the distribution will generally
> be consistent with the copy of config.guess that it contains.

It's not as though this change will be terrifically damaging, as long as
people replacing config.guess check that it still works as expected on
Solaris boxes...

... but that check may be unlikely to happen: it's not as though
config.guess triplets frequently change, or are *expected* to change.

-- 
`I have some desires that would probably consume the entire lifetime
 power output of one G-type star.' --- Mark Atwood

Re: flag day for Solaris portions of config.{guess,sub}

[Branko Čibej]

Richard Stallman wrote:

>Are you saying that config.guess is widely used outside of configure
>scripts?
>  
>
Yes. For a myriad of purposes.


-- 
Brane ÄŒibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Richard Stallman <rms@gnu.org> writes:

>     Paul Eggert already presented evidence that roughly 10% of a sample of
>     configure.in scripts not only look at the configuration name, but
>     match it against patterns containing the string "solaris" or "sunos".
>     To my mind that is enough to rule out the proposed change as too costly.
>
> I'm surprised it is so many.  As someone pointed out, the real extent of
> the problem depends on how many of them check the version number as well
> as the name.  It should be pretty easy to measure that too.

Haven't we wasted enough time arguing about this proposal?  The gain
is trivial - a tiny inconsistency removed - how can it possibly be
worth the effort even of measuring the exact scope of the disruption
it will cause?

>     And, for the third time, Autoconf is not the only user of
>     config.guess/config.sub.
>
> The point is that most programs nowadays use Autoconf, so other uses are
> few.

That turns out not to be the case.  cfengine is a good example of a
program in an entirely different problem domain that uses canonical
system names.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Ben Elliston]

"Zack Weinberg" <zack@codesourcery.com> writes:

> That turns out not to be the case.  cfengine is a good example of a
> program in an entirely different problem domain that uses canonical
> system names.

I think we can conclude the discussion here.  I'm convinced that the
proposed change is both (a) trivial enough to not bother wasting any
more time arguing over it, and (b) would have too much impact on
users (both of Autoconf and auxillary config.* users).

Also--thanks to everyone for bringing my attention to uses of these
scripts in other domains I wasn't aware of!

Ben

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Ben Elliston <bje@wasabisystems.com> writes:

> I'm convinced that the proposed change ... would have too much
> impact on users (both of Autoconf and auxillary config.* users).

OK, how about the following more-conservative change instead?  This
patch uses correct version numbers for future versions of SunOS /
Solaris, while leaving the existing incorrect numbers in place.  This
is an upward compatible change that shouldn't affect existing code
that depends on the existin numbers, and this should avoid the
backward-compatibility hassles that have been mentioned in this
thread.


2003-12-04  Paul Eggert  <eggert@twinsun.com>

	* config.guess, config.sub: Use names like "sunos5.10" for future
	Solaris versions, thus fixing the incorrect version numbers
	(like "solaris2.9") in the old scheme.

diff -pru config/config.guess config-sunos/config.guess
--- config/config.guess	Sun Nov 23 21:42:42 2003
+++ config-sunos/config.guess	Thu Dec  4 13:29:46 2003
@@ -136,6 +136,43 @@ UNAME_RELEASE=`(uname -r) 2>/dev/null` |
 UNAME_SYSTEM=`(uname -s) 2>/dev/null`  || UNAME_SYSTEM=unknown
 UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
 
+case "${UNAME_SYSTEM}" in
+SunOS)
+    # Solaris 2.0 - 2.6 (SunOS 5.0 - 5.6) are "solaris2.0" - "solaris2.6",
+    # and Solaris 7 - 9 (SunOS 5.7 - 5.9) are "solaris2.7" - "solaris2.9".
+    # This numbering scheme is incorrect, and in retrospect it would have
+    # been better to use SunOS versions (namely, "sunos5.0" - "sunos5.9").
+    # However, many configure scripts depend on this behavior,
+    # so use the traditional scheme for SunOS 5.0 through 5.9.
+    # Starting with SunOS 5.10, use sunos names uniformly (e.g., "sunos5.10").
+    # As SunOS 5.9 and earlier become obsolete the incorrect numbering
+    # problem should also become obsolete.
+
+    # If you prefer using "sunos" names uniformly, set
+    # CONFIG_PREFERS_SUNOS="true" in your environment,
+    # or modify the following line to read "true" rather than "false".
+    CONFIG_PREFERS_SUNOS_DEFAULT=false
+
+    case "${UNAME_MACHINE}:${UNAME_RELEASE}" in
+    sun4*:[0-4].*)
+	case "`/usr/bin/arch -k`" in
+	    Series*|S4*)
+		UNAME_RELEASE=$UNAME_VERSION ;;
+	esac ;;
+    esac
+
+    # Use "sunos" names if they are preferred; otherwise use the
+    # traditional misnumbering scheme.
+    CONFIG_PREFERS_SUNOS=${CONFIG_PREFERS_SUNOS-$CONFIG_PREFERS_SUNOS_DEFAULT}
+    case "${CONFIG_PREFERS_SUNOS}:${UNAME_RELEASE}" in
+	true:* | *:[0-4].* | *:5.[1-9][0-9]*)
+	     # Japanese Language versions have a version number like `4.1.3-JL'.
+	     sun_os_release=sunos`echo ${UNAME_RELEASE}|sed -e 's/-/_/g'` ;;
+	*)
+	     sun_os_release=solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//' -e 's/-/_/'` ;;
+    esac ;;
+esac
+
 # Note: order is significant - the case branches are not exclusive.
 
 case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
@@ -337,29 +374,14 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
 	case `/usr/bin/uname -p` in
 	    sparc) echo sparc-icl-nx7 && exit 0 ;;
 	esac ;;
-    sun4H:SunOS:5.*:*)
-	echo sparc-hal-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+    sun4H:SunOS:*:*)
+	echo sparc-hal-$sun_os_release
 	exit 0 ;;
-    sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
-	echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+    sun4*:SunOS:*:* | tadpole*:SunOS:*:*)
+	echo sparc-sun-$sun_os_release
 	exit 0 ;;
     i86pc:SunOS:5.*:*)
-	echo i386-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
-	exit 0 ;;
-    sun4*:SunOS:6*:*)
-	# According to config.sub, this is the proper way to canonicalize
-	# SunOS6.  Hard to guess exactly what SunOS6 will be like, but
-	# it's likely to be more like Solaris than SunOS4.
-	echo sparc-sun-solaris3`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
-	exit 0 ;;
-    sun4*:SunOS:*:*)
-	case "`/usr/bin/arch -k`" in
-	    Series*|S4*)
-		UNAME_RELEASE=`uname -v`
-		;;
-	esac
-	# Japanese Language versions have a version number like `4.1.3-JL'.
-	echo sparc-sun-sunos`echo ${UNAME_RELEASE}|sed -e 's/-/_/'`
+	echo i386-pc-$sun_os_release
 	exit 0 ;;
     sun3*:SunOS:*:*)
 	echo m68k-sun-sunos${UNAME_RELEASE}
@@ -377,7 +399,7 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
 	esac
 	exit 0 ;;
     aushp:SunOS:*:*)
-	echo sparc-auspex-sunos${UNAME_RELEASE}
+	echo sparc-auspex-$sun_os_release
 	exit 0 ;;
     # The situation for MiNT is a little confusing.  The machine name
     # can be virtually everything (everything which is not
@@ -807,7 +829,7 @@ EOF
 	echo powerpcle-unknown-cygwin
 	exit 0 ;;
     prep*:SunOS:5.*:*)
-	echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	echo powerpcle-unknown-$sun_os_release
 	exit 0 ;;
     *:GNU:*:*)
 	# the GNU system
diff -pru config/config.sub config-sunos/config.sub
--- config/config.sub	Sun Nov 23 21:42:43 2003
+++ config-sunos/config.sub	Wed Dec  3 15:04:23 2003
@@ -1110,15 +1110,27 @@ esac
 
 if [ x"$os" != x"" ]
 then
+
+# Deal with "traditional" names (-solaris*) versus "sunos" names (-sunos*)
+# for SunOS 5.0 through 5.9.  See config.guess for details.
+# If you prefer using "sunos" names uniformly, set
+# CONFIG_PREFERS_SUNOS="true" in your environment,
+# or modify the following line to read "true" rather than "false".
+CONFIG_PREFERS_SUNOS_DEFAULT=false
+CONFIG_PREFERS_SUNOS=${CONFIG_PREFERS_SUNOS-$CONFIG_PREFERS_SUNOS_DEFAULT}
+
 case $os in
         # First match some system type aliases
         # that might get confused with valid system types.
-	# -solaris* is a basic system type, with this one exception.
+	# Traditional -solaris* is a basic system type, with this one exception.
 	-solaris1 | -solaris1.*)
 		os=`echo $os | sed -e 's|solaris1|sunos4|'`
 		;;
 	-solaris)
-		os=-solaris2
+		case "$CONFIG_PREFERS_SUNOS" in
+		    true) os=-sunos5 ;;
+		    *)    os=-solaris2 ;;
+		esac
 		;;
 	-svr4*)
 		os=-sysv4
@@ -1135,6 +1147,7 @@ case $os in
 	# -sysv* is not here because it comes later, after sysvr4.
 	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
 	      | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[34]*\
+	      | -sunos5.[1-9][0-9]* | -sunos[6-9]* | -sunos[1-9][0-9]* \
 	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
 	      | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \
 	      | -aos* \
@@ -1182,11 +1195,11 @@ case $os in
 	-linux*)
 		os=`echo $os | sed -e 's|linux|linux-gnu|'`
 		;;
-	-sunos5*)
-		os=`echo $os | sed -e 's|sunos5|solaris2|'`
-		;;
-	-sunos6*)
-		os=`echo $os | sed -e 's|sunos6|solaris3|'`
+	-sunos5.[0-9] | -sunos5.[0-9].*)
+		case "$CONFIG_PREFERS_SUNOS" in
+		    true) ;;
+		    *) os=`echo $os | sed -e 's|sunos5|solaris2|'` ;;
+		esac
 		;;
 	-opened*)
 		os=-openedition

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Paul Eggert <eggert@CS.UCLA.EDU> writes:

> Ben Elliston <bje@wasabisystems.com> writes:
>
>> I'm convinced that the proposed change ... would have too much
>> impact on users (both of Autoconf and auxillary config.* users).
>
> OK, how about the following more-conservative change instead?  

This still requires a nonzero number of autoconf scripts to change and
is therefore unacceptable.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Arnaud Charlet]

> OK, how about the following more-conservative change instead?  This

Please don't, that'd be worse.

SunOS no longer means anything, so this should really be solaris7,
solaris8, solaris9, etc... And solaris10 if this is how the next version
of Solaris will be called.

While I agree that this issue has already been discussed too much,
I also strongly disagree about the apparent conclusion: nobody has provided
any real figure about the impact of this change, only assumptions and
personal feelings.

Also, changing new config.guess won't break existing packages, so we're
talking about new packages using new version of config.guess, and a very
low amount of packages that will need to be changed.

The amount of changes will be lower than the amount of changes required
to switch from one version of autoconf to another, and lower or equal to
the amount of work required to support a new version of Solaris, so I
really don't see any convincing argument for using the wrong names.

The official names for Solaris are clear, and I don't see any reason
to use non existing versions, leading to clearly incorrect names.

Arno

Re: flag day for Solaris portions of config.{guess,sub}

[Alexandre Oliva]

On Dec  4, 2003, Paul Eggert <eggert@CS.UCLA.EDU> wrote:

> Ben Elliston <bje@wasabisystems.com> writes:
>> I'm convinced that the proposed change ... would have too much
>> impact on users (both of Autoconf and auxillary config.* users).

> OK, how about the following more-conservative change instead?

I like the approach, but I think we'd be better off using solaris10
for Solaris 10/SunOS 5.10, just because then solaris* would still
match.  Solaris 10 is more like Solaris 2+ than SunOS 4, which most
sunos* matches would get.  At which point, we could probably do
without the preference switches.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: flag day for Solaris portions of config.{guess,sub}

[Joe Buck]

On Thu, Dec 04, 2003 at 09:04:38PM -0200, Alexandre Oliva wrote:
> I like the approach, but I think we'd be better off using solaris10
> for Solaris 10/SunOS 5.10, just because then solaris* would still
> match.  Solaris 10 is more like Solaris 2+ than SunOS 4, which most
> sunos* matches would get.  At which point, we could probably do
> without the preference switches.

Agreed; if we are going to make a change, it should preserve "solaris"
and abandon the "sunos".
 

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Joe Buck <jbuck@synopsys.com> writes:

> On Thu, Dec 04, 2003 at 09:04:38PM -0200, Alexandre Oliva wrote:
>> I like the approach, but I think we'd be better off using solaris10
>> for Solaris 10/SunOS 5.10, just because then solaris* would still
>> match.  Solaris 10 is more like Solaris 2+ than SunOS 4, which most
>> sunos* matches would get.  At which point, we could probably do
>> without the preference switches.
>
> Agreed; if we are going to make a change, it should preserve "solaris"
> and abandon the "sunos".

I still haven't seen even a weak argument for making any change at
all.  So the canonical system names are inconsistent with Sun's
marketing names; why does anyone even care?

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Ben Elliston]

"Zack Weinberg" <zack@codesourcery.com> writes:

> I still haven't seen even a weak argument for making any change at
> all.  So the canonical system names are inconsistent with Sun's
> marketing names; why does anyone even care?

Some people care because the output of config.guess does not match the
well-known name by which that operating system and version are known.
This is, admittedly, potentially confusing to newbies who think they
are using a Solaris 7 system and config.guess tells them they are
using Solaris 2.7.

Ben

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Ben Elliston <bje@wasabisystems.com> writes:

> Some people care because the output of config.guess does not match the
> well-known name by which that operating system and version are known.
> This is, admittedly, potentially confusing to newbies who think they
> are using a Solaris 7 system and config.guess tells them they are
> using Solaris 2.7.

Okay, but I can't countenance that as justification for any kind of
incompatible change, not even one that only changes behavior for as
yet unreleased versions of Solaris.  (People have already written
configure scripts that expect Solaris 10 will be identified as
*-sun-solaris2.10.)

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Alexandre Oliva]

On Dec  4, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:

> (People have already written configure scripts that expect Solaris
> 10 will be identified as *-sun-solaris2.10.)

Should we care about those who have guessed wrong?  I think it would
be ok for us to report *-sun-solaris10 for Solaris 10 and above.  It
wouldn't break the property for earlier OSs.

The only catch is that earlier config.guess scripts would (probably)
still report sparc-sun-solaris2.10, so newer configure scripts could
be written based on this dated assumption and break.  But people are
encouraged to ship new software using the latest copies of these
files, so I don't consider this a big deal.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> Should we care about those who have guessed wrong?  I think it would
> be ok for us to report *-sun-solaris10 for Solaris 10 and above.

What if Sun's marketing department renames Solaris 11 into Solaris G3?

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Alexandre Oliva]

On Dec  6, 2003, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:

>> Should we care about those who have guessed wrong?  I think it would
>> be ok for us to report *-sun-solaris10 for Solaris 10 and above.

> What if Sun's marketing department renames Solaris 11 into Solaris G3?

Well, then it's not Solaris 11 :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> > What if Sun's marketing department renames Solaris 11 into Solaris G3?
>
> Well, then it's not Solaris 11 :-)

I can't disagree with you :-)

But what triplet would you choose for it?  Maybe *-sun-solaris3.0.  And since 
they are not that dumb at Sun :-), the next one could be named Solaris G3 
Release 2, which would be triplet-ed as *-sun-solaris3.2.

So you will end up with the *-sun-solaris2.* series and the *-sun-solaris3.* 
series and in the middle... *-sun-solaris10.  At which point you may want to 
eat the first Sun employee within your reach :-)

I think we'd better keep the current naming [solarisx.y for sunos(3+x).y] for 
the whole SunOS 5.x series.  When the technical guys decide to switch to 
SunOS 6.x, we'll organize a naming contest :-)

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Arnaud Charlet]

> But what triplet would you choose for it?  Maybe *-sun-solaris3.0.  And since 

I find that amazing to use hypothetical names in this discussion,
it shows that you are running out of arguments :-)

The (hypothetical) name would of course be *-sun-solarisg3.0 or something like
that, I don't see any problem, so why create one ?

Choosing names is not a technical issue, no technical people should not
be allowed to choose, based on what they believe is 'The Right Thing' to
decide what the 'proper' next solaris version should be :-)

I understand that Solaris marketing department has created confusion among
part of the technical people, but that does not warrant to get the names
wrong forever.

This has lead in the past to other strangeness and confusion, the most
obvious one being of course to name the pentium 'i586', and then continue
with the i686, ...

Arno

Re: flag day for Solaris portions of config.{guess,sub}

[Eric Botcazou]

> I find that amazing to use hypothetical names in this discussion,
> it shows that you are running out of arguments :-)

It's called foresight.  Never suppose the worst will never happen :-)

> The (hypothetical) name would of course be *-sun-solarisg3.0 or something
> like that, I don't see any problem, so why create one ?

I see a problem: you would have to explicitly special-case *-sun-solaris10 in 
your patterns.  And you would of course forget in some cases.

> This has lead in the past to other strangeness and confusion, the most
> obvious one being of course to name the pentium 'i586', and then continue
> with the i686, ...

Which is nice since you can use i?86.  I think config.sub can accept whatever 
fancy names you want, but config.guess should make it easy to parse its 
output.

-- 
Eric Botcazou

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Arnaud Charlet <charlet@ACT-Europe.FR> writes:

> Choosing names is not a technical issue,

These particular names exist for programs to process, which makes it a
technical issue.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Russ Allbery]

Ben Elliston <bje@wasabisystems.com> writes:

> Some people care because the output of config.guess does not match the
> well-known name by which that operating system and version are known.
> This is, admittedly, potentially confusing to newbies who think they are
> using a Solaris 7 system and config.guess tells them they are using
> Solaris 2.7.

I've got to say that this is rather unlikely to confuse anyone who's been
administering Solaris for any length of time.  Heck, every Solaris admin
that I know personally called Solaris 7 Solaris 2.7 instead, and Solaris
2.8 wasn't at all uncommon.

It's just the actual Solaris version with "2." prepended.  I don't think
it's going to confuse anyone too badly, and it's the sort of confusion
that's pretty readily remedied.

(Oh, and please, don't make any version of Solaris identify itself as
"sunos" anything.  That would break every Autoconf script I have that
cares about Solaris as a platform.  -solaris10 wouldn't break nearly as
much.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: flag day for Solaris portions of config.{guess,sub}

[Alexandre Oliva]

On Dec  5, 2003, Russ Allbery <rra@stanford.edu> wrote:

> Heck, every Solaris admin that I know personally called Solaris 7
> Solaris 2.7 instead

Just as a funny data point, there is a Solaris admin at the uni who
used to mistakenly say Solaris 6 long before Sun changed their naming
conventions and released Solaris 7 when everybody was expecting 2.7.
I started calling her a psychic visionary at that point :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

Alexandre Oliva <aoliva@redhat.com> writes:

> I like the approach, but I think we'd be better off using solaris10
> for Solaris 10/SunOS 5.10, just because then solaris* would still

This is completely premature: Sun employees are currently (e.g. during all
talks on the Sun Network Conference in Berlin) very careful to only talk
about `Solaris Next', since the real name of the beast is not yet clear.
So we cannot change to *-*-solaris10 until the product is released.  At
that time, the will be a considerable number of packages supporting SunOS
5.10 in various ways (I've personally contributed to GCC, am-utils, and
ntp), and all of them would have to change again to accomodate the new
name.  This is a completely unnecessary waste of effort, as is this whole
discussion.

Fortunately, nobody so far proposed to change alpha*-dec-osf* to
alpha*-compaq-osf* to alpha*-compaq-tru64* to alpha*-hp-tru64*... to match
Compaq purchasing DEC, the O/S name change and the Compaq/HP merger (and
Paul Eggert doesn't seem to be using the platform to worry about this ;-).
As you can clearly see from this example, the proposed change is utterly
absurd.

	Rainer

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

> Sun employees are ... very careful to only talk about `Solaris
> Next', since the real name of the beast is not yet clear.  So we
> cannot change to *-*-solaris10 until the product is released.

That is why my proposal was to switch to -sunos5.10 instead, as that
name is more stable (and has already been decided on within Sun).

One other advantage of fixing the numbering problem between SunOS 5.9
and SunOS 5.10 is that configure scripts tend to be buggy in this
area.  For example, they might use a pattern like *-solaris2.[0-6]* to
match Solaris 2.0, ..., 2.5, 2.5.1, 2.6, but with the current
config.guess this pattern now unexpectedly matches the output of SunOS
5.10 (which config.guess currently calls "solaris2.10").  Since SunOS
5.10 will require maintainers who care about SunOS version numbers to
review their configure scripts for unexpected pattern matches anyway,
having them convert to -sunos5.10 is no big deal.  It may even
simplify their patterns a bit.

As I understand it, the major suggestions for my latest proposal are:

(a) Use -solaris10 rather than -sunos5.10.  I argue against this above,
    basically in agreement with your earlier messages on this subtopic.

(b) Wait until SunOS 5.11, since a few packages already deal with
    prerelease versions of SunOS 5.10.  This argument holds less
    weight than the previous backward-compatibility arguments, since
    such packages are dealing with prerelease software and have to be
    prepared to change anyway.  I also argued against this above
    (in the "One other advantage" paragraph).

(c) Don't make the change at all; just keep the incorrect numbering
    indefinitely.

Obviously (c) is something I'm against fairly strongly, or I wouldn't
have brought up this issue in the first place.  I'm quite aware of the
entrenched software that depends on the wrong version numbers, but I
also feel strongly that we should give operating systems proper names
and numbers.  This should have been fixed years ago, but better late
than never.

For (a) and (b), I still prefer my most recent proposed patch, but if
Ben prefers a different option I can code it up.  Ben, what's your
pleasure?

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

Paul Eggert writes:

> That is why my proposal was to switch to -sunos5.10 instead, as that
> name is more stable (and has already been decided on within Sun).
> 
> One other advantage of fixing the numbering problem between SunOS 5.9
> and SunOS 5.10 is that configure scripts tend to be buggy in this
> area.  For example, they might use a pattern like *-solaris2.[0-6]* to
> match Solaris 2.0, ..., 2.5, 2.5.1, 2.6, but with the current
> config.guess this pattern now unexpectedly matches the output of SunOS
> 5.10 (which config.guess currently calls "solaris2.10").  Since SunOS
> 5.10 will require maintainers who care about SunOS version numbers to
> review their configure scripts for unexpected pattern matches anyway,
> having them convert to -sunos5.10 is no big deal.  It may even
> simplify their patterns a bit.

... and force everyone else (who had their patterns correct or don't
require Solaris version-specific handling) to change their configure
etc. scripts?  For what gain?  Why can't you seem to understand the value
of backwards compatibility?  In all this discussion, the only argument in
favor of change has been reduced (newbie) confusion and consistency with
vendor nomenclature.  I would have thought that my example of the DEC OSF/1
-> Digital UNIX -> Tru64 UNIX name changes together with the vendor change
from DEC -> Digital -> Compaq -> HP had made it completely clear that
following vendor marketing ideas creates a maintenance nightmare for
config.{guess, sub} users, but you don't seem to get that point.  Or will
your next crusade be to change alpha*-dec-osf* as well?  At this point, you
cannot even be sure that `Solaris Next' will actually be called `Solaris'
at all; maybe they come up with some fancy Java-based name a few days
before the release ;-(

> (c) Don't make the change at all; just keep the incorrect numbering
>     indefinitely.
> 
> Obviously (c) is something I'm against fairly strongly, or I wouldn't
> have brought up this issue in the first place.  I'm quite aware of the
> entrenched software that depends on the wrong version numbers, but I
> also feel strongly that we should give operating systems proper names
> and numbers.  This should have been fixed years ago, but better late
> than never.

(c) is clearly the only option, especially since the only gain of change is
consistence with (inherently inconsistent and changing) vendor marketing
whims.  You could have made this change in the Solaris 2.0 days, but not
after the current scheme has been in use for 10 years.

Besides, I think this is all moot now since Ben already declared that there
will be no change due to the massive impact compared to minimal benefit.

	Rainer

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> Paul Eggert writes:
>> (c) Don't make the change at all; just keep the incorrect numbering
>>     indefinitely.
>> 
>> Obviously (c) is something I'm against fairly strongly, or I wouldn't
>> have brought up this issue in the first place.  I'm quite aware of the
>> entrenched software that depends on the wrong version numbers, but I
>> also feel strongly that we should give operating systems proper names
>> and numbers.  This should have been fixed years ago, but better late
>> than never.
>
> (c) is clearly the only option, especially since the only gain of change is
> consistence with (inherently inconsistent and changing) vendor marketing
> whims.  You could have made this change in the Solaris 2.0 days, but not
> after the current scheme has been in use for 10 years.

I agree.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Paul Eggert]

Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

> this is all moot now since Ben already declared that there will be
> no change due to the massive impact compared to minimal benefit.

Ben didn't say that there would be no change.  He merely rejected my
original proposal on the grounds of backwards compatibility.  Ben
hasn't commented on my revised proposal, which addressed his objection
by maintaining backward compatibility on all current platforms.

> Why can't you seem to understand the value of backwards compatibility?

I understand it quite well.  I also understand the value of using
correct version numbers instead of incorrect ones.  There are
competing advantages here.  Backwards compatibility does not trump all
other issues.  Otherwise programs like GCC would never withdraw any
features, which obviously is not the case.

> following vendor marketing ideas creates a maintenance nightmare

Yes, and that is why the proposed change improves on the existing
config.guess, by avoiding vendor marketing terms like "Solaris" in
future (unreleased) operating systems.

> will your next crusade be to change alpha*-dec-osf*

No; that OS is dying, and isn't worth the effort.

Re: flag day for Solaris portions of config.{guess,sub}

[Alexandre Oliva]

On Dec  8, 2003, Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:

> (c) is clearly the only option, especially since the only gain of change is
> consistence with (inherently inconsistent and changing) vendor marketing
> whims.  You could have made this change in the Solaris 2.0 days, but not
> after the current scheme has been in use for 10 years.

There's another reason to change from solaris2.10 to something else:
to avoid matches on say solaris2.[0-6]* from matching 2.10.
Backward-compatibility is not an argument to make it solaris2.10: it
*will* expose brokenness.  We could do better by using solaris10,
since those that use solaris* will still match, and those that use
2.[0-6]* won't inappropriately match.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: flag day for Solaris portions of config.{guess,sub}

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Dec  8, 2003, Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:
>
>> (c) is clearly the only option, especially since the only gain of change is
>> consistence with (inherently inconsistent and changing) vendor marketing
>> whims.  You could have made this change in the Solaris 2.0 days, but not
>> after the current scheme has been in use for 10 years.
>
> There's another reason to change from solaris2.10 to something else:
> to avoid matches on say solaris2.[0-6]* from matching 2.10.
> Backward-compatibility is not an argument to make it solaris2.10: it
> *will* expose brokenness.  We could do better by using solaris10,
> since those that use solaris* will still match, and those that use
> 2.[0-6]* won't inappropriately match.

*sigh* Must we continue this?

configure scripts (and things which are not configure scripts) already
exist which _correctly_ match, say, solaris2.[789] | solaris2.1[0-9] .
Not exposing bugs in other scripts that have solaris2.[0-6]* is not a
reason to break correct scripts.

zw

Re: flag day for Solaris portions of config.{guess,sub}

[Rainer Orth]

Alexandre Oliva writes:

> There's another reason to change from solaris2.10 to something else:
> to avoid matches on say solaris2.[0-6]* from matching 2.10.
> Backward-compatibility is not an argument to make it solaris2.10: it
> *will* expose brokenness.  We could do better by using solaris10,
> since those that use solaris* will still match, and those that use
> 2.[0-6]* won't inappropriately match.

But as I wrote before, solaris10 will likely be wrong by the time SunOS
5.10 is released, because it will probably be called otherwise.

Just stay with solaris2.* and be done with this nonsense (and discussion).

	Rainer

Re: flag day for Solaris portions of config.{guess,sub}

[Richard Stallman]

    That turns out not to be the case.  cfengine is a good example of a
    program in an entirely different problem domain that uses canonical
    system names.

That is an interesting point.

Re: flag day for Solaris portions of config.{guess,sub}

[Andrew Cagney]

>     > Don't we know that most programs that use Autoconf don't actually look
>     > at the configuration name at all?
> 
>     Paul Eggert already presented evidence that roughly 10% of a sample of
>     configure.in scripts not only look at the configuration name, but
>     match it against patterns containing the string "solaris" or "sunos".
>     To my mind that is enough to rule out the proposed change as too costly.
> 
> I'm surprised it is so many.  As someone pointed out, the real extent of
> the problem depends on how many of them check the version number as well
> as the name.  It should be pretty easy to measure that too.
> 
>     And, for the third time, Autoconf is not the only user of
>     config.guess/config.sub.
> 
> The point is that most programs nowadays use Autoconf, so other uses are
> few.

Just FYI, there's something of a gap between the theory and the 
[unfortunate] reality here.  To quote GDB's internals doco:

``GDB's host configuration support normally happens via Autoconf. New 
host-specific definitions should not be needed. Older hosts GDB still 
use the host-specific definitions and files listed below, but these 
mostly exist for historical reasons, and will eventually disappear.''

Two observations:

- This upstream change would serve as a useful trigger for making a few 
more of those configurations "disappear".

- There's only marginal return in trying to 100% covert programs such as 
GDB to autoconf (not stopping anyone from trying mind :-).  Far easier 
to let the old systems bit rot and die - trimming them as dead wood in a 
year or so.

Andrew