Date: Sun, 05 Aug 2012 20:58:19 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Gerald Pfeifer <gerald@pfeifer.com> Cc: Brendan Fabeny <bf1783@gmail.com>, freebsd-ports@FreeBSD.org, Kevin Oberman <kob6558@gmail.com> Subject: Re: lang/gcc46 Message-ID: <501F40DB.900@FreeBSD.org> In-Reply-To: <alpine.LNX.2.00.1207311746060.2533@gerinyyl.fvgr> References: <CAGFTUwNbj0mDrdu40dwkmECLhrc0Uwap=8UKi=tbBgRCTvZTMQ@mail.gmail.com> <alpine.LNX.2.00.1207300152200.2533@gerinyyl.fvgr> <5015D122.4040608@FreeBSD.org> <alpine.LNX.2.00.1207311746060.2533@gerinyyl.fvgr>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?501F40DB.900>