For the record,

On Sat, Oct 25, 2025 at 11:43:02AM +0200, Rafael Sadowski wrote:
> On Sat Oct 25, 2025 at 09:56:12AM +0100, Stuart Henderson wrote:
> > These GCC49_ARCHS are "archs where ports-gcc >4.9 exists". GCC4_ARCHS is a
> > totally different thing, "archs where the compiler in base is gcc 4", the
> > two are not interchangeable.
> 
> Thank you for the explanation. From my point of view, it is
> certainly confusing.

The "gcc49" naming is confusing because it embeds a version.  But that
doesn't change the fact that it is about a different compiler and that
the property is populated according to a different list (GCC49_ARCHS).
I still think we should rename the variable and property.

> > freebasic: I don't see why this is conditional, the port only builds on
> > ports-gcc archs. "XXX only pulls this if it actually exists" doesn't make
> > much sense.

Yep.

> > The various gcc4.port.mk files should have a MODGCC4_CDEP or
> > similar (similar to MODGCC4_CPPDEP) that ports can use so they don't need to
> > hardcode versions (as in the RUN_DEPENDS) and then free basic can use that.
> > 
> > numpy: I don't think that needs to be conditional either?

For numpy: at some point riscv64 didn't have gcc49 support, but I
managed to build numpy without fortran support, as it would
automatically fall back on bundle of C files converted using
f2c.  This was also useful at some point for aarch64:

  -.if ${PROPERTIES:Mgcc49}
  +# XXX - disable on aarch64 until fortran compiler is fixed
  +.if ${PROPERTIES:Mgcc49} && ${MACHINE_ARCH} != aarch64

Nowadays both aarch64 and riscv64 have gcc49/fortran support.  The
other archs lacking gcc49 also don't have clang support so they have
no modern C compiler at all; and numpy requires a compiler newer than
base-gcc anyway:

  ERROR: Problem encountered: NumPy requires GCC >= 8.4

Already committed, but that was ok jca@.  Thanks!

-- 
jca