Re: A better method to require compiler features

[Greg Troxel <gdt%lexort.com@localhost>]

Havard Eidnes <he%NetBSD.org@localhost> writes:

>> This seems like a great approach.  Splitting the features into
>> fine-grained things addresses the issue of "need C++NN implies gcc foo"
>> not being quite right.  And critically for me, it avoids open-coding of
>> gcc versions in every package, which while a longstanding workaround, is
>> icky, hard to deal with, and fails to deal with other compilers.
>
> I agree.  Some features require a minimum version of GCC (if gcc
> is the C++ compiler) due to language construct support in the
> compiler itself, while some features appear to require a given
> minimum version of GCC due to required libstdc++ support for the
> given feature, either in the form of header file support or an
> actual implementation as code in libstdc++ itself.

Sure, but that's all "to use language feature foo you need gcc X and
matching lib".

I expect there will remain a small number of "gcc 8 miscompiles this
particular code, so require 9 or higher".

> However, there be dragons here, and the danger is that you might
> end up using several different GCC versions to build c++-using
> libraries, programs or program suites.  The different gcc
> versions have different major versions for their libstdc++
> libraries, and have, if I've understood correctly, limited (if
> we're being generous) backwards binary compatibility.  It
> certainly doesn't help that the shared library versioning scheme
> used by in-tree g++ for libstdc++ is different from the one used
> by the gcc versions in pkgsrc.
>
> The consequence is that it is quite easy to end up with final
> executables which calls for multiple different major versions of
> libstdc++, and that's not going to work well.

[warning: my bias is that C++14 is a langauge and C++ is a language family]

Yes, but this has nothing to do with the proposal on the table, which is

  move from

    USE_LANGUAGES defining which C++ language family member is needed,
    even though that is unimplemented
    
    ad hoc use of GCC_REQD as  a workaround for not having a good way to
    express which language is needed.    

  to

    USE_LANGUAGES just says C++

    USE_CXX_FEATURES defines which specific language and which specific
    features that are not necessarily bound to a language.


Both of those situations have *exactly the same* multiple-gcc-in-use
problems, so that objection is orthogonal.  A proposal to mitigate it
is fine -- just not relevant to the USE_CXX_FEATURES discussion.
 
> Instead, for a bulk build we probably need to rely on the rather
> more heavy-handed approach of using a given gcc version and use
> it to build all the c++ programs and libraries in pkgsrc.  And if
> we're to support the maximum number of packages, that
> "maximalizes" the required GCC version number (if gcc is being
> used as the compiler).
>
> ...and that in itself also has issues, in that it becomes more
> difficult or at least more work to mix binary packages and
> self-built packages on the same system (yes, I know, that's not
> officially supported, which doesn't mean it's not being done...),
> as you then as a user needs to use that same c++ compiler as the
> one who built the binary packages if you're locally building c++-
> using packages.

It's all difficult.  This is why I was suggesting (separate logical
thread) to have as a rule "if the base gcc isn't good enough, use
version X", rather than using the minimum version for the feature.
That could be baked into platform.mk with a default, so that it would be
part of official bulk builds.

There's also the auto-admin approach of requiring new gcc for all except
things needed to build gcc. Again a separate discussion.

The issue of not mixing packages that are built with one set of knob
settings with another is not going to be fixed; what I think we should
strive for is to end up with defaults that are broadly good enough so
people don't *want* to set knobs very often.