From owner-freebsd-stable@FreeBSD.ORG Thu Sep 16 04:24:34 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B30616A4CE; Thu, 16 Sep 2004 04:24:34 +0000 (GMT) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.213.1.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F8B543D5D; Thu, 16 Sep 2004 04:24:33 +0000 (GMT) (envelope-from crossd@cs.rpi.edu) Received: from monica.cs.rpi.edu (root@monica.cs.rpi.edu [128.213.7.2]) i8G4OW0o022653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2004 00:24:32 -0400 (EDT) Received: from monica.cs.rpi.edu (crossd@localhost [127.0.0.1]) by monica.cs.rpi.edu (8.12.9p2/8.12.6) with ESMTP id i8G4OW2j024104; Thu, 16 Sep 2004 00:24:32 -0400 (EDT) (envelope-from crossd@monica.cs.rpi.edu) Received: from localhost (crossd@localhost)i8G4OWtM024101; Thu, 16 Sep 2004 00:24:32 -0400 (EDT) (envelope-from crossd@monica.cs.rpi.edu) Date: Thu, 16 Sep 2004 00:24:32 -0400 (EDT) From: "David E. Cross" To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, re@freebsd.org Message-ID: <20040916000619.B22029@monica.cs.rpi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.43 Subject: 5.3, libstc++, gcc34 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 04:24:34 -0000 I recently upgraded my 5.2.1-RELEASE-p# laptop to 5.3-BETA3 in order to help test things out. (Well, first I updated to BETA2, but I got nailed by the UDMA ICH3 bug... that is fixed thankfully). What I got nailed by now is gcc34 and C++ ABI changing. That's not "our" fault, I understand and respect that. What is our fault is not protecting the user from these changes. There are a fair number of people out there, early adopters, who installed the 5.x-"RELEASE" branches (I emphasize the fact the these were advertised as "-RELEASE" by "us"), who will now be screwed as a result, with their only choice (other than playing library whack-a-mole... which I have spent 5+hours on already on my personal laptop) is a complete reinstall from scratch. Many will find this unacceptable; If I were a lesser user, I would. There is a solution to this, bump the version number on the c++ libraries in the core OS. We have done this before for other GCC ABI changes, I believe we even did this _within_ the 4.x-STABLE branch (I could be mistaken on this). What happens if we "don't" do this: 1) We screw early adopters, those who have run "-RELEASE" and helped us get the bugs out, get performance numbers, etc. These people may not be developers, they really can be (and are) end users. 2) We screw application vendors who have developed code and products using c++ for the 5.x branch (or just linked against libraries that then link to c++) 3) We screw end developers (like I have at my location), who have started developing and using code, rebuilding is not always an easy option. What happens if we "do" do this (by "do" I mean bump version numbers): 1) We DON'T screw people following any of the 5.x-RELEASE branches 2) We screw those following -CURRENT... but this isn't stable anyway, and they/we are told to expect this type of breakage. 3) We screw the beta testers, potentially. They either had to do fresh installs or reinstalls anyway, they don't have any substantial infrastructure invested in the current system. In short, as a vendor of a major OS, I would screw OS developers, and beta testers NUMEROUS times before ever touching the end user; especially for a product that has been -RELEASEed for over a year. -- David E. Cross