Re: Why NOARCH packages aren't available on all architectures?

On 2022-Aug-6, at 00:42, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Aug-5, at 23:51, Yuri <yuri@FreeBSD.org> wrote:
> 
>> On 8/5/22 13:19, Mark Millard wrote:
>>> Part of what is going on is that having a NOARCH end result
>>> can still involve the build using build-environment-ARCH
>>> specific toolchains.
>> 
>> 
>> You are implying that NOARCH packages should be built on each architecture individually.
> 
> You may well have a suggestion for portmgr_at_FreeBSD.org about combining
> materials from independent poudriere bulk runs from separate machines,
> but you asked:
> 
> QUOTE
> Shouldn't packages which are NOARCH be equally available on all 
> architectures?
> END QUOTE
> 
> That said nothing about such an idea. I would never have guessed
> from your wording what you apparently were actually asking/thinking.
> I thought that you thought that armv6 did not try to build NO_ARCH
> ports --instead of it being a temporary build problem.
> 
> You also asked:
> 
> QUOTE
> What causes this not to be the case?
> END QUOTE
> 
> I tried to explain how things actually work currently for the
> NOARCH failures, but that was under my misinterpretation if
> your intent.
> 
>> But NOARCH packages fit any architecture, regardless of where they are built. Once successfully built on one architecture they should become available for all architectures.
> 
> There is no combining of poudriere bulk run results from separate
> machines/architectures at this time.  You certainly can ask
> portmgr@FreeBSD.org about such ideas.
> 
>> It's amazing that this isn't what is happening.
> 
> portmgr might classify it as more-effort/too-complicated-to-manage
> than it is worth, expecting that most NOARCH builds work most of
> the time on most of the architectures.
> 
> 
> But, looking up https://github.com/xtensor-stack/xsimd reports:
> 
> QUOTE
> The following SIMD instruction set extensions are supported:
> 
> Architecture	Instruction set extensions
> x86	SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, FMA3+SSE, FMA3+AVX, FMA3+AVX2
> x86	AVX512BW, AVX512CD, AVX512DQ, AVX512F (gcc7 and higher)
> x86 AMD	FMA4
> ARM	NEON, NEON64
> END QUOTE
> 
> So, for FreeBSD, the following platforms are not supported
> from what I can tell:
> (from https://www.freebsd.org/platforms/ , other than adding
> powerpc64le)
> 
> TARGET_ARCH's:
> 
arm
armv6
> mips, misel
> misphf, mipselhf
> mipsn32
> mips64, misp64el
> mips64hf, mips64elhf
> powerpc
> powerpcspe
> powerpc64
> powerpc64le
> riscv64
> riscv64sf
> sparc64
> 
> [I'm unsure about 32-bit ARMv4/5 "arm" (no v6/v7).]

Turns out that "arm" and "armv6" both do not have NEON.
But armv7 does.

> I'll note that the powerpc*'s are still listed as
> Tier 2 for "Projected 14.x" and all the mips*'s
> are listed for "13.x". sparc64 is listed only
> for 12.x .
> 
> That appears to be far from a NO_ARCH context for FreeBSD.

Note: I was thinking of architectures that likely could not pass
the do-test target. I'd not made that clear, sorry.

But devel/xsimd was probably only intended as an example and there
would be others, so the xsimd details are not as important.


Hmm. Turns out that the issue you are after is documented to some
degree in https://docs.freebsd.org/en/books/porters-handbook/porting-dads/ :

QUOTE
13.14.2. Marking a Port as Architecture Neutral
Ports that do not have any architecture-dependent files or requirements are identified by setting NO_ARCH=yes.

NO_ARCH is meant to indicate that there is no need to build a package for each of the supported architectures. The goal is to reduce the amount of resources spent on building and distributing the packages such as network bandwidth and disk space on mirrors and on distribution media. Currently, however, our package infrastructure (e.g., package managers, mirrors, and package builders) is not set up to fully benefit from NO_ARCH.
END QUOTE

So a "known issue" as far as I can tell.


===
Mark Millard
marklmi at yahoo.com