lang/gcc46

[b. f.]

On 8/6/12, Doug Barton <dougb at freebsd.org> wrote:
> On 07/31/2012 08:57, Gerald Pfeifer wrote:
>> On Sun, 29 Jul 2012, Doug Barton wrote:

<skipping quibbles and polemics>

> 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.

For the most part, yes.  The upstream developers have a policy of
avoiding version bumps for the runtime support libraries when
possible, and instead using symbol versioning to maintain
backward-compatibility.  Only a very few pieces of software using
libgcj or libobjc will have to be recompiled.  For default packages,
IIRC, that is only print/pdftk.  Of course, it will be to the
advantage of most users to recompile their packages with the new
version of the compiler.

>> 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. :)

I think Gerald was referring to Bapt's plan to make it easier to make
multiple packages from a single port, so that those who used packages
exclusively could install a package consisting of only the runtime
support libraries, rather than the whole compiler suite.  I had
patches to do this even without pkgng, but it made things a little
more complicated, and didn't seem to be a high priority, so I didn't
pursue it.  If people feel that it is important, I could work with
Gerald to revive that, or use a knob like that of ports/155408 with
static linking to allow users to remove the runtime dependency for a
lot of software, at the cost of some added overhead from redundancies.

b.