From owner-freebsd-ports@FreeBSD.ORG Mon Aug 6 03:58:20 2012 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9BEFC106564A for ; Mon, 6 Aug 2012 03:58:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 362EE14E014; Mon, 6 Aug 2012 03:58:20 +0000 (UTC) Message-ID: <501F40DB.900@FreeBSD.org> Date: Sun, 05 Aug 2012 20:58:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Gerald Pfeifer References: <5015D122.4040608@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brendan Fabeny , freebsd-ports@FreeBSD.org, Kevin Oberman Subject: Re: lang/gcc46 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 03:58:20 -0000 On 07/31/2012 08:57, Gerald Pfeifer wrote: > On Sun, 29 Jul 2012, Doug Barton wrote: >>> lang/gcc and lang/gcc46 should be fully compatible, without rebuilds >>> necessary. Only when lang/gcc is going to move to GCC 4.7 later this >>> year would I consider that. >> IMO this highlights the issue that unversioned instances of ports that >> really need versioning (like gcc) are a bad idea. It's much better for >> users to be able to tie their installations to a particular version, and >> then only update when they need to. The fact that someday in the future >> users who innocently upgrade lang/gcc will suddenly find that everything >> relying on libgcc at runtime is now broken pretty much speaks for itself. > > The fact that I would consider that, was not supposed to imply > breakage. :-) I was more thinking better optimization and other > benefits. I'm not asking you to agree with me that the current situation is broken. I'm merely pointing out that it *is* broken, and pointing out solid, non-broken examples that we already have. > In my day job, we have been doing upgrades from GCC 4.x to GCC 4.x+y > run-times quite successfully and without any breakage more than once. > And we've got many, quite many, users. Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. > In other words, if there is a challenge it's not GCC per se, more > our packaging of it (and some work Bapt is doing on the packaging > infrastructure should help with that). I don't know of any magic solutions in the works that will solve the separation of libgcc from the compiler. :) Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)