tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: First go at adding GCC_VERSIONS_ACCEPTED support

David Sainty <> writes:

>> Then, we shouldn't need GCC_REQD in C++ packages, and we can use the
>> min/objectioable scheme in C, since we can mix?
> I've thought about this approach a few times too.  Probably allowing
> the user to override it addresses my minor concern that it might force
> some users to build a GCC on very purpose-specific systems where they
> may prefer not to.

That can be ok, but this either gets hairy or unsound.

> GCC_REQD is sometimes used to avoid GCC bugs present in a range of
> versions, not just to ensure certain features are present.  I think in
> principle that a package should be able to state an explicit GCC
> minimum, as well as relying on the default USE_LANGUAGES handling.

That is leading me to want the basic mechanism (new enough for defined
features) to be separate from the exception mechanism.

> Assuming that we default to, say, GCC 4.9 for C++ - I think that means
> for most people PKGSRC_GCC_MIN should be 4.9 for C packages too.
> I.e. if we're expecting to build GCC 4.9 as soon as we hit a C++
> package, maybe the default preference should be to use that version
> for C packages too, if and only if the native version isn't good
> enough for some package or other.

This seems to be a tension between repeatable builds, bloat and concern
about mixing versions.  I think repeatable builds should be a key

So I would like to see each USE_LANGUAGES name define clearly (in a
comment) what it means, and to have a specified gcc version to meet
those requirements, and use it.  That can lead to C and C++ being
different, and we can either avoid that now or later, if we have real
evidence of problems.

So that could lead to


with the expectation that this results in using the system version if >=
and otherwise requires exactly that version built from pkgsrc.   With
perhaps the extra logic that if the base system does not satisfy
PKGSRC_GCC_MIN, then build/require PKGSRC_GXX_MIN.

If it turns out to be a bad to mix, we can just  set them equal.

For C, MIN might end up being a version with atomics, as I've seen
packages not build with 4.1 and build with 4.5.  I'm unclear how that
interacts with standards.  Or perhaps those get handled with GCC_REQD,
and that logic will pick PKGSRC_GXX_MIN if it's good enough.

For GCC_REQD, I am hoping that the number of instances will be very
small, and we could perhaps just let it be until we get a handle on how
much is needed.

> If there isn't a compelling reason to choose 4.9, I suggest 4.8
> instead as a default.  Grep says that nothing in Pkgsrc explicitly
> requires beyond 4.8 - though there are several that call for 4.8 as a
> minimum.  GCC 4.8 is the current default native for Ubuntu and related
> long term support installations, so we will support at least those
> users a bit better if we don't force a 4.9 build on them.

I agree, partly because NetBSD 7 has 4.8.  Aside from introduction of
new features like C++11 support, it would seem broken of gcc if any
non-broken package demanded a higher version.   There are always going
to be issues, and it's a question of spreading the pain.

All in all, I think the first step is to force >= 4.8 for C++ builds.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index