Re: FreeBSD:14:armv7 not recently updated
- In reply to: Mark Millard : "Re: FreeBSD:14:armv7 not recently updated "
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 27 Mar 2024 18:42:02 UTC
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 : > > On 2024-03-27 12:57:49 (+0800), Philip Paeps wrote: > >>> On 2024-03-22 16:36:36 (+0800), Graham Perrin wrote: >>> >>>> <https://pkg.freebsd.org/FreeBSD:14:armv7/> neither base_weekly nor >>>> base_latest has been updated since January. >>>> >>>> Please, what's the plan? >>>> >>>> (Not for me, personally, but relevant to a discussion in Discord.) >>> >>> I'm looking into it. (Wearing my clusteradm hat.) >> >> It looks like gohan05 is building freebsd:14:armv7:32:el:eabi:softfp and >> pkgsync only knows about freebsd:14:armv7:32:el:eabi:hardfp. >> >> Should we be building hardfp or syncing softfp? >> >> (same goes for 13 and 15) > > > For the softfp context, what does the likes of the following > show? > > # readelf -h /usr/bin/uname | grep "Flags:" > Flags: 0x5000400, Version5 EABI, VFP > > The "4" indicates the VFP status EF_ARM_ABI_FLOAT_HARD. Does it show: > > Flags: 0x5000200, Version5 EABI, soft-float ABI > > ? (The "2" indicates soft-float ABI. EF_ARM_ABI_FLOAT_SOFT) > > Does it show some other combination of bits? > > See: > > https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#52elf-header > > See also: > > https://github.com/llvm/llvm-project/blob/main/lld/ELF/InputFiles.cpp#L107 > 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. === Mark Millard marklmi at yahoo.com