For example: * cad/kicad-devel - https://pkg-status.freebsd.org/ampere2/data/main-armv7-default/pf323e9d40f68_s41be508d31/logs/kicad-devel-r20221009002759_4.log * math/py-ducc0 - https://pkg-status.freebsd.org/ampere3/data/131releng-armv7-default/387f99b7180f/logs/py39-ducc0-0.27.0.log * science/py-PyNE - https://pkg-status.freebsd.org/ampere2/data/main-armv7-default/pf323e9d40f68_s41be508d31/logs/py39-PyNE-0.7.7_3.log This is happening for a long time.
The builders for armv7 have plenty of ram. I believe that the problem is that those ports often do not build fine for 32bits architectures. pkgmgr can not help here.
This must be a toolchain (clang) problem because a dozen different ports all fail with out of memory error on only armv7.
(In reply to Yuri Victorovich from comment #2) I’m not aware of clang or gcc requiring all builds to work inside the likes of “only” around 2 GiByte or 3 GiByte process size limitations. Aarch64 machines that can execute armv7/aarch32 code in the likes of a chroot can have smaller process size limits than some non-aarch64 armv7 machines do in native FreeBSD use. None of the FreeBSD buildservers are such 32-bit only armv7 machines.
(In reply to Mark Millard from comment #3) Going in the other direction, far less builds under qemu on amd64 or the like so the current status is a big, fairly recent, improvement to the armv7/v6 port builds.
(In reply to Mark Millard from comment #4) I should not have mentioned armv6. Those still are qemu based. FreeBSD does not support armv6 chroots or the like on aarch64 that can do such, at least without modification of some FreeBSD source code. The simple way to enable armv6 disables armv7. Allowing both would be a bigger change. (I once helped someone make a kernel that supported armv6 instead of armv7 on the aarch64 system. Swapping kernel boot choices allowed swapping between the 2 kinds of support.)