Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Aug 2022 00:42:18 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Yuri <yuri@FreeBSD.org>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: Why NOARCH packages aren't available on all architectures?
Message-ID:  <F9CA59DB-D9E9-48FB-B4F4-C8154542A26B@yahoo.com>
In-Reply-To: <a304fced-8617-b375-cf27-7399b6f4638e@tsoft.com>
References:  <689E23B1-BBF8-4A08-AC20-2CFABFB981AA.ref@yahoo.com> <689E23B1-BBF8-4A08-AC20-2CFABFB981AA@yahoo.com> <a304fced-8617-b375-cf27-7399b6f4638e@tsoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
>=20
>=20
> 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=20
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:

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).]

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.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F9CA59DB-D9E9-48FB-B4F4-C8154542A26B>