Re: C++20 and gcc12/10

[Jonathan Perkin <jperkin%pkgsrc.org@localhost>]

* On 2025-04-06 at 18:28 BST, Havard Eidnes wrote:

> > No, this belongs in infrastructure.  A package should only have to
> > declare what it needs in terms of compiler support, not have
> > OS-specific hacks spread across them.  Since adding support for
> > *_FEATURES there shouldn't be any GCC_REQD in packages.
>
> Well.
>
> What to do when "older" GCCs do not produce a working result?
> Such as e.g. gcc < 12 fails to build a working LLVM 18.x as part
> of the rust package on sparc64?  That's sort of hard to express
> using the *_FEATURES settings.
>
> Same goes for our 32-bit powerpc ports needing GCC >= 14 to build
> without falling over with
>
> assertion "memcmp(mf_ptr(mf) - 1, mf_ptr(mf) - matches[i].dist - 2, matches[i].len) == 0" failed: file "xz-5.2/src/liblzma/lz/lz_encoder_mf.c", line 40, function "lzma_mf_find"
>
> (tested and failed both with in-tree gcc10 and pkgsrc gcc12 on
> NetBSD/macppc 10.0)

The way I'd do that is to add this to mk/platform/NetBSD.mk:

  .if ${MACHINE_ARCH} == "sparc64"
  GCC_REQD+=	12
  .elif ${MACHINE_ARCH} == "powerpc"
  GCC_REQD+=	14
  .endif

then it fixes all packages and not just rust and xz.  But yes, I accept 
the point that there may be certain situations where GCC_REQD might be 
required in very limited circumstances.  The point was more that where 
the logic _can_ be encoded in USE_*_FEATURES it _should_ be.

--
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com