No longer immediately relevant after the revert. Worth discussing the venn diagram regarding __ISO_C_VISIBLE et al since there are gotchas in C as well.

revert to initial diff

use __STDC_VERSION__ to ensure visibility only on C23 and later

There shouldn't be C23-compliant codebases that define their own unreachable(). Based on my understanding of sys/sys/_visible.h, it looks like __ISO_C_VISIBLE is getting defined as 2023 almost unconditionally, at least in base, so it leaked into jemalloc. It may leak into other C codebases if a standard is not explicitly passed or other macros defined during build steps.

In D53433#1232130, @michaelo wrote:

@vishwin Have you had time to check the updated patch? The distutils approach is now behind a switch, being an opt-in.

In D53433#1223609, @arrowd wrote:

In D53433#1223585, @michaelo wrote:

Here is the definition: https://packaging.python.org/en/latest/specifications/binary-distribution-format/

There is a notion of a "platform tag" which denotes the platform for which the wheel has been built if it contains native code, by default it does "$(os}_${release}_${arch}". Run " pip debug --verbose" and see for compatible tags. If a wheel has been compiled with 13.5-RELEASE-p5 it won't be consumed by 13.5-RELEASE-p6. "wheel tags --remove --platform-tag=..." renames the file for multiplatform AND modfies the metadata (Tag: ) in WHEEL file. So I am not rebuilding, I am retagging. I first assumed a bug in poudriere: https://github.com/freebsd/poudriere/issues/1277, but then realized otherwise.

Well, to me it is the python part that should be fixed. FreeBSD guarantees ABI compatibility between minor releases, so the tag should look like py310-none-freebsd_13_amd64. This is the same how pkg handles our native packages ABI.

In D53433#1224442, @michaelo wrote:

In D53433#1224438, @vishwin wrote:

USES=distutils is going away because upstream is removing support for this entirely. It had been deprecated for quite some time but they are finally pulling the switch.

I know, this is why I said that with PEP 517 wheels already there, they just need to be in a distinct, explicit place for consumption.

Can you explain why this change needs revision? ATM, I don't see a way to make it even simple than this. Again, I don't expect you do upload anthing to PyPI. It is just a possible usecaes. I am happy if people can host their own indexes with this.

In D53433#1223076, @michaelo wrote:

My ideal longterm goal: The Project hosts canonical poudriere builds and these could produce FreeBSD-specific wheels which could be uploaded to PyPI and would dramatically improve the situation for the Python ecosystem on FreeBSD.

sync reference to libuuid

• lang/python313: update to 3.13.9

In D52146#1191167, @kevans wrote:

e.g., routers, which likely don't want to drop some valuable storage on GCC. You'll note in the PR that they're just running py-duckdb, which has numpy as a dependency but doesn't really need BLAS.

This is not numpy's problem. I also commented in the PR but it bears repeating, anything built with GCC, including with gfortran in this case, needs the GCC libraries to operate properly. flang exists but I haven't had a chance to try building with it yet, but is part of the larger overhaul.

If you're toggling non-default options on a port like numpy, you really need to understand the consequences of it.

In the Python world, we cannot underestimate pilot errors. You need to consider the userbase of numpy, many of whom are not necessarily as versed in software like we are, and just see "ooh reduce dependency". Disabling fortran support is a pretty fatal one.

As for the proposed changes themselves, these will not apply after numpy is switched to building under PEP-517, amongst other things.

Can you suggest a better approach that would be compatible going forawrd? (When is the PEP-517 switch actually going to happen?)

It's been in my tree for quite some time, but simply missing some sanity checks.

It's unfortunate that we couldn't have gotten python@ feedback of this sort on this at any point in the last three years that the PR has been open- I guess we need more python@ staffing. =\

It's also unfortunate that the Python ecosystem overall has a very particular way of doing things and is a mess to even start learning.

Please elaborate further on "in some case this can be needed in some specifics environment to not have such dependencies." numpy isn't exactly meant to run on constricted environments, and fortran and BLAS support are generally considered fundamental components. Adding these options invites noise from those shooting themselves in the foot.

False alarm. Turns out pkgbase's plist logic relies on at least staging changes in git (no need to commit).

pkgbase fails:

===> Creating FreeBSD-kernel-malvern-15.snap20250627004823
rm -f /usr/home/vishwin/boards/malvern/obj/usr/src/amd64.amd64/sourcestage/src.plist 2>/dev/null || :
/usr/src/release/packages/generate-ucl.lua  PKGNAME "src"  PKGGENNAME "src"  VERSION "15.snap20250627004823"  DESC "FreeBSD Kernel Sources"  COMMENT "FreeBSD Userland Sources"  PKG_NAME_PREFIX "FreeBSD"  PKG_MAINTAINER "re@FreeBSD.org"  PKG_WWW "https://www.FreeBSD.org"  /usr/src/release/packages/template.ucl  /usr/home/vishwin/boards/malvern/obj/usr/src/amd64.amd64/sourcestage/src.ucl
pkg -o ABI=FreeBSD:15:amd64  -o OSVERSION="1500048"  create -f tzst -l -1  -M /usr/home/vishwin/boards/malvern/obj/usr/src/amd64.amd64/sourcestage/src.ucl  -p /usr/home/vishwin/boards/malvern/obj/usr/src/amd64.amd64/sourcestage/src.plist  -r /usr/src  -o /usr/home/vishwin/boards/malvern/obj/usr/src/repo/FreeBSD:15:amd64/15.snap20250627004823
rm -f /usr/home/vishwin/boards/malvern/obj/usr/src/amd64.amd64/sourcestage/src-sys.plist 2>/dev/null || :
/usr/src/release/packages/generate-ucl.lua  PKGNAME "src-sys"  PKGGENNAME "src"  VERSION "15.snap20250627004823"  DESC "FreeBSD Kernel Sources"  COMMENT "FreeBSD Kernel Sources"  PKG_NAME_PREFIX "FreeBSD"  PKG_MAINTAINER "re@FreeBSD.org"  PKG_WWW "https://www.FreeBSD.org"  /usr/src/release/packages/template.ucl  /usr/home/vishwin/boards/malvern/obj/usr/src/amd64.amd64/sourcestage/src-sys.ucl
pkg -o ABI=FreeBSD:15:amd64  -o OSVERSION="1500048"  create -f tzst -l -1  -M /usr/home/vishwin/boards/malvern/obj/usr/src/amd64.amd64/sourcestage/src-sys.ucl  -p /usr/home/vishwin/boards/malvern/obj/usr/src/amd64.amd64/sourcestage/src-sys.plist  -r /usr/src  -o /usr/home/vishwin/boards/malvern/obj/usr/src/repo/FreeBSD:15:amd64/15.snap20250627004823
pkg: Unable to access file /usr/src/sys/dev/sound/midi/sequencer.c:No such file or directory
pkg: Unable to access file /usr/src/sys/dev/sound/midi/sequencer.h:No such file or directory
*** Error code 1