Date: Sat, 6 Aug 2022 01:13:45 -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: <E069439B-2586-4D75-83F4-C7DBEF3190CF@yahoo.com> In-Reply-To: <F9CA59DB-D9E9-48FB-B4F4-C8154542A26B@yahoo.com> References: <689E23B1-BBF8-4A08-AC20-2CFABFB981AA.ref@yahoo.com> <689E23B1-BBF8-4A08-AC20-2CFABFB981AA@yahoo.com> <a304fced-8617-b375-cf27-7399b6f4638e@tsoft.com> <F9CA59DB-D9E9-48FB-B4F4-C8154542A26B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> 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. >=20 > 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: >=20 > QUOTE > Shouldn't packages which are NOARCH be equally available on all=20 > architectures? > END QUOTE >=20 > 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. >=20 > You also asked: >=20 > QUOTE > What causes this not to be the case? > END QUOTE >=20 > I tried to explain how things actually work currently for the > NOARCH failures, but that was under my misinterpretation if > your intent. >=20 >> 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. >=20 > 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. >=20 >> It's amazing that this isn't what is happening. >=20 > 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. >=20 >=20 > But, looking up https://github.com/xtensor-stack/xsimd reports: >=20 > QUOTE > The following SIMD instruction set extensions are supported: >=20 > 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 >=20 > So, for FreeBSD, the following platforms are not supported > from what I can tell: > (from https://www.freebsd.org/platforms/ , other than adding > powerpc64le) >=20 > TARGET_ARCH's: >=20 arm armv6 > mips, misel > misphf, mipselhf > mipsn32 > mips64, misp64el > mips64hf, mips64elhf > powerpc > powerpcspe > powerpc64 > powerpc64le > riscv64 > riscv64sf > sparc64 >=20 > [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 . >=20 > 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=3Dyes. 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. =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?E069439B-2586-4D75-83F4-C7DBEF3190CF>