Date: Wed, 27 Mar 2024 11:42:02 -0700 From: Mark Millard <marklmi@yahoo.com> To: Philip Paeps <philip@freebsd.org>, FreeBSD-pkgbase@freebsd.org Cc: Baptiste Daroussin <bapt@FreeBSD.org> Subject: Re: FreeBSD:14:armv7 not recently updated Message-ID: <DC3E0CAF-B22E-449E-8A09-89CFACCF22F3@yahoo.com> In-Reply-To: <914C9B0E-7C38-400B-A159-D26BD7E87F54@yahoo.com> References: <914C9B0E-7C38-400B-A159-D26BD7E87F54@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 27, 2024, at 08:42, Mark Millard <marklmi@yahoo.com> wrote: > Philip Paeps <philip_at_freebsd.org> wrote on > Date: Wed, 27 Mar 2024 05:11:12 UTC : >=20 > On 2024-03-27 12:57:49 (+0800), Philip Paeps wrote: >=20 >>> On 2024-03-22 16:36:36 (+0800), Graham Perrin wrote: >>>=20 >>>> <https://pkg.freebsd.org/FreeBSD:14:armv7/>; neither base_weekly nor=20= >>>> base_latest has been updated since January. >>>>=20 >>>> Please, what's the plan? >>>>=20 >>>> (Not for me, personally, but relevant to a discussion in Discord.) >>>=20 >>> I'm looking into it. (Wearing my clusteradm hat.) >>=20 >> It looks like gohan05 is building freebsd:14:armv7:32:el:eabi:softfp = and=20 >> pkgsync only knows about freebsd:14:armv7:32:el:eabi:hardfp. >>=20 >> Should we be building hardfp or syncing softfp? >>=20 >> (same goes for 13 and 15) >=20 >=20 > For the softfp context, what does the likes of the following > show? >=20 > # readelf -h /usr/bin/uname | grep "Flags:" > Flags: 0x5000400, Version5 EABI, VFP >=20 > The "4" indicates the VFP status EF_ARM_ABI_FLOAT_HARD. Does it show: >=20 > Flags: 0x5000200, Version5 EABI, = soft-float ABI >=20 > ? (The "2" indicates soft-float ABI. EF_ARM_ABI_FLOAT_SOFT) >=20 > Does it show some other combination of bits? >=20 > See: >=20 > = https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#52elf= -header >=20 > See also: >=20 > = https://github.com/llvm/llvm-project/blob/main/lld/ELF/InputFiles.cpp#L107= >=20 The suggestion was rather incomplete. Where to look can involve: A) the root dir. that package is supposed to be using as a prefix on the normal paths. The normal paths (that might be prefixed): B) the env. var path: ABI_FILE C) /usr/bin/uname D) /bin/sh But the logic in pkg_get_myarch_elfparse seems bad to me: It tries in the order, finding the first match, . . . PREFIXED getenv(ABI_FILE) getenv(ABI_FILE) PREFIXED /usr/bin/uname /usr/bin/uname PREFIXED /bin/sh /bin/sh Thus, for, say, aarch64 with a root dir. PREFIX for pkg to find the = armv7 materials in, it could stop at and use the first found non-PREFIXED = (i.e., aarch64 file) match if the earlier PREFIXED did not match, never = checking the later PREFIXED alternatives. aarch64 Flag: lines show as . . . # readelf -h /usr/bin/uname | grep Flags: Flags: 0 Not having the 0x400, such would be classified as softfp by the code that checks against the: #ifndef EF_ARM_VFP_FLOAT #define EF_ARM_VFP_FLOAT 0x00000400 #endif value. It looks to me like the order should be: PREFIXED getenv(ABI_FILE) PREFIXED /usr/bin/uname PREFIXED /bin/sh then, failing finding a match, possibly: getenv(ABI_FILE) /usr/bin/uname /bin/sh But it is not clear to me that ignoring the root dir. PREFIX is really appropriate if it is non-empty. =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?DC3E0CAF-B22E-449E-8A09-89CFACCF22F3>