Re: A better method to require compiler features

[Havard Eidnes <he%NetBSD.org@localhost>]

>> In light of recent discussions, I would like to add a
>> new variable to the pkgsrc infrastructure. It could
>> will be used in the following ways:
>>
>> USE_CXX_FEATURES+=	c++14
>>
>> To require at least GCC 7, but not NetBSD gcc 7:
>>
>> USE_CXX_FEATURES+=	filesystem
>>
>> To require at least GCC 4.9:
>>
>> USE_CXX_FEATURES+=	regex
>>
>> This would set the appropriate GCC_REQD without intefering
>> with the compiler wrappers.
>
> 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.

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.

Earlier I made as an experiment an attempt with NetBSD/macppc 8.0
to tweak the qt5-qtbase Makefile.common like this:

--- Makefile.common     21 Nov 2022 18:12:17 -0000      1.50
+++ Makefile.common     13 Jul 2023 15:33:34 -0000
@@ -34,7 +34,11 @@
 WRKSRC=                ${WRKDIR}/${DISTNAME:S/-opensource//}
 
 # https://doc.qt.io/qt-5/supported-platforms.html
-GCC_REQD+=     5
+
+# But ... because kde now relies on c++17, we need gcc7 for
+# an implementation of that, and so as to try to avoid mixing
+# in-tree libstdc++.so.8 with pkgsrc's gcc7's libstdc++.so.7
+GCC_REQD+=     7
 
 .include "../../x11/qt5/Makefile.common"
 
However, that ultimately failed, and the build fell into the trap
of "multiple different libstdc++ major versions linked into the
same program" problem stated above.  The reason is that KDE also
uses other c++-implemented libraries outside of the KDE / QT5
sphere (and therefore didn't end up looking in the
Makefile.common above) and many of these libraries have more lax
requirements for the c++ language version needed than KDE / QT5
itself, so those ended up being built with the in-tree c++
compiler, resulting in different libstdc++ major versions being
referenced.

So...  I've tentatively, and at least to myself concluded that
while tweaking each package to state more explicitly its own
requirements for c++ feature support is a laudable goal (it's
going to be quite a bit of work...), it's probably not going to
end up properly sorting this mess out for a pkgsrc bulk build(?)
Theoretically it possibly could, since pbulk knows the dependency
graph, and within each "cone" you could maxmalize the gcc version
requirements of all the packages in a given sub-graph.  But is
that in effect going to be different or better than the approach
described in the next paragraph?

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.

Regards,

- Håvard