From: Paul Eggert <eggert@CS.UCLA.EDU>
To: Ben Elliston <bje@wasabisystems.com>
Cc: "Zack Weinberg" <zack@codesourcery.com>,
rms@gnu.org, gcc@gcc.gnu.org, binutils@sources.redhat.com,
gdb@sources.redhat.com
Subject: Re: flag day for Solaris portions of config.{guess,sub}
Date: Thu, 04 Dec 2003 21:41:00 -0000 [thread overview]
Message-ID: <87r7zkb6xm.fsf@penguin.cs.ucla.edu> (raw)
In-Reply-To: <8765gwvowl.fsf@wasabisystems.com>
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
next prev parent reply other threads:[~2003-12-04 21:37 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-20 12:25 Ben Elliston
2003-11-20 14:03 ` Ben Elliston
2003-11-20 14:12 ` Eric Botcazou
2003-11-20 18:29 ` Rainer Orth
2003-11-20 20:31 ` Paul Eggert
2003-11-20 20:35 ` Rainer Orth
2003-11-20 20:50 ` Albert Chin-A-Young
2003-11-20 21:32 ` Paul Eggert
2003-11-20 21:44 ` Rainer Orth
2003-11-21 0:57 ` Paul Eggert
2003-11-21 1:15 ` Rainer Orth
2003-11-23 12:51 ` Richard Stallman
2003-11-23 23:40 ` Branko Čibej
2003-11-24 8:17 ` Paul Eggert
2003-11-24 8:28 ` Eric Botcazou
2003-11-24 12:08 ` Paul Eggert
2003-11-24 14:35 ` Eric Botcazou
2003-11-24 21:54 ` Paul Eggert
2003-11-25 10:47 ` Eric Botcazou
2003-11-25 23:12 ` Paul Eggert
2003-11-26 6:05 ` Eric Botcazou
2003-11-26 12:05 ` Ben Elliston
2003-11-27 1:58 ` Russ Allbery
2003-11-25 10:07 ` Richard Stallman
2003-11-26 3:49 ` Zack Weinberg
2003-11-20 21:33 ` Eric Botcazou
2003-11-20 21:40 ` Rainer Orth
2003-11-20 23:32 ` Phil Edwards
2003-11-21 23:56 ` tm_gccmail
2003-11-22 0:01 ` Joe Buck
2003-11-27 18:55 ` Zack Weinberg
2003-11-29 1:42 ` Paul Eggert
2003-11-29 2:24 ` Zack Weinberg
2003-12-01 21:29 ` Paul Eggert
2003-12-01 22:09 ` Zack Weinberg
2003-12-02 21:40 ` Paul Eggert
2003-12-02 21:45 ` Zack Weinberg
2003-12-02 22:21 ` Ben Elliston
2003-12-03 17:22 ` Richard Stallman
2003-12-03 17:23 ` Zack Weinberg
2003-12-03 17:33 ` Arnaud Charlet
2003-12-04 7:42 ` Richard Stallman
2003-12-04 8:57 ` Branko Čibej
2003-12-05 17:27 ` Richard Stallman
2003-12-05 18:43 ` Zack Weinberg
2003-12-05 18:53 ` Joe Buck
2003-12-06 12:11 ` Nix
2003-12-07 23:22 ` Branko Čibej
2003-12-04 10:16 ` Zack Weinberg
2003-12-04 11:16 ` Ben Elliston
2003-12-04 21:41 ` Paul Eggert [this message]
2003-12-04 22:07 ` Zack Weinberg
2003-12-04 23:04 ` Arnaud Charlet
2003-12-04 23:11 ` Alexandre Oliva
2003-12-04 23:27 ` Joe Buck
2003-12-04 23:38 ` Zack Weinberg
2003-12-04 23:41 ` Ben Elliston
2003-12-04 23:42 ` Zack Weinberg
2003-12-05 11:46 ` Alexandre Oliva
2003-12-06 7:05 ` Eric Botcazou
2003-12-06 20:41 ` Alexandre Oliva
2003-12-06 21:56 ` Eric Botcazou
2003-12-07 9:25 ` Arnaud Charlet
2003-12-07 15:26 ` Eric Botcazou
2003-12-07 19:25 ` Zack Weinberg
2003-12-05 5:00 ` Russ Allbery
2003-12-05 12:37 ` Alexandre Oliva
2003-12-08 13:29 ` Rainer Orth
2003-12-08 22:44 ` Paul Eggert
2003-12-08 23:48 ` Rainer Orth
2003-12-08 23:59 ` Zack Weinberg
2003-12-10 0:04 ` Paul Eggert
2003-12-12 5:30 ` Alexandre Oliva
2003-12-12 7:19 ` Zack Weinberg
2003-12-12 21:27 ` Rainer Orth
2003-12-05 23:22 ` Richard Stallman
2003-12-04 14:22 ` Andrew Cagney
2003-11-20 21:55 bkorb
2003-11-20 23:24 ` Rainer Orth
2003-11-20 23:52 ` Bruce Korb
2003-12-02 22:58 Wolfgang Bangerth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r7zkb6xm.fsf@penguin.cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=binutils@sources.redhat.com \
--cc=bje@wasabisystems.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sources.redhat.com \
--cc=rms@gnu.org \
--cc=zack@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).