From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13025 invoked by alias); 20 Nov 2003 19:14:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13017 invoked from network); 20 Nov 2003 19:14:39 -0000 Received: from unknown (HELO mailout.TechFak.Uni-Bielefeld.DE) (129.70.136.245) by sources.redhat.com with SMTP; 20 Nov 2003 19:14:39 -0000 Received: from xayide.TechFak.Uni-Bielefeld.DE.TechFak.Uni-Bielefeld.DE (xayide.TechFak.Uni-Bielefeld.DE [129.70.137.35]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7p1+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id hAKJEW127388; Thu, 20 Nov 2003 20:14:32 +0100 (MET) From: Rainer Orth Message-ID: <16317.4758.255402.870324@xayide.TechFak.Uni-Bielefeld.DE> Date: Thu, 20 Nov 2003 20:35:00 -0000 To: Paul Eggert Cc: Ben Elliston , gcc@gcc.gnu.org, binutils@sources.redhat.com, gdb@sources.redhat.com, rms@gnu.org Subject: Re: flag day for Solaris portions of config.{guess,sub} In-Reply-To: <87k75u98bu.fsf@penguin.cs.ucla.edu> References: <8765hf4c8z.fsf@wasabisystems.com> <87k75u98bu.fsf@penguin.cs.ucla.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2003-11/txt/msg01120.txt.bz2 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=F6rg 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