Re: 2026Q1 and USE_CXX_FEATURES+=c++20

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

Edgar Fuß <ef%math.uni-bonn.de@localhost> writes:

> Upgrading to 2025Q4 and then to 2026Q1 I see an increasing number of packages 
> bumping USE_CXX_FEATURES from c++17 to c++20. On -10, this inflicts gcc12, 
> thus a non-base C++ compiler with all the resulting potential C++ library 
> incompatibilities, on me.
>
> I've patched that to c++17 (plus filesystem for libheif) in graphics/libheif, 
> print/poppler (Makefile.common, buildlink3.mk) and print/qpdf and built all 
> my packages with the base gcc10.
>
> So, what problem is this trying to solve? Is it that packages compile with 
> gcc10, but fail to function? Is it that linking to specific programs I 
> don't use doesn't work? Is it specific for -9?

As wiz@ said, if upstream documents C++20, either in actual
documentation or a configure test, we set it.

The root causes of your woes are a varying blend (depending on your
attitudes) of

  NetBSD's unreasonably long release cycle.  NetBSD 10 was released 2
  years ago.  More importantly it was branched a year before that.
  https://netbsd.org/releases/formal.html#history

  Upstream's willingness to use new C++ standards.

  Our unwillingness to slice a standard into dozens of parts and expend
  lots of effort to validate which gcc versions support which subsets
  and try to avoid requiring new gcc.   This is likely not the real
  issue in many cases, as upstream should add --std=foo and verify that
  the compiler accepts it.

At least you aren't using things in rust, with rust being in the base
system :-)

> compiler/gcc.mk says:
> # gcc documents that 11 is required, with a few perhaps-obscure
> # features requiring 12.  gcc10 does not define __cplusplus as meeting
> # c++20.

If you think that isn't accurate, please cite upstream docs.

> print/qpdf/Makefile says:
> # fix build on NetBSD/9.4
> # -- Performing Test ATOMIC_WORKED0
> # CMake Error in /tmp/print/qpdf/work/qpdf-12.3.2/cmake-pkgsrc-build/CMakeFiles/CMakeScratch/TryCompile-g61khV/CMakeLists.txt:
> #   Target "cmTC_f6cd8" requires the language dialect "CXX20" .  But the
> #   current compiler "GNU" does not support this, or CMake does not know the
> Couldn't at least this be limited to -9?

Given that upstream checks for c++20, the comment should be dropped.
The bug was really "upstream needs c++20 but the package was coded for
c++17 (which was probably the requirement in earlier versions".  The
standard approach is to read upstream's docs/configure-scripts and
translate those to our variables, and that's in the general case
unremarkable.  I just dropped the comment.