Re: How do I determine the ABI string used by pkg?

From: Mark Millard <>
Date: Sun, 05 Mar 2023 18:08:14 UTC
On Mar 5, 2023, at 09:54, Mark Millard <> wrote:

> Mel Pilgrim <> wrote on
> Date: Thu, 02 Mar 2023 07:50:13 UTC :
>> I need to determine the ABI string pkg uses on a given system, and need 
>> to do so when there are no pkgs installed.
> There may be more to that question than you are expecting
> and you may have to establish more about what you want
> (and why).
> pkg itself is a package and so you have specified it is not
> installed. You have not indicated why pkg can not be installed
> the normal way and then used. (The question might be if this
> can be unblocked or not.)
> You have not indicated the range of system versions to be
> covered. 12..14? All?
> What about when an LP64 architecture is supported for also
> running an ILP32 counterpart, so there are 2 ABIs?
> LP64      ILP32 counterpart
> amd64     i386
> powerpc64 powerpc
> mips64*   mips*
> aarch64   armv6/armv7
> (I question the accuracy of the armv6 in the "man 7 arch"
> table, although I could change the kernel to switch from
> armv7 to armv6 as the counterpart --and once helped someone
> build a special kernel that did so.)
> So how do you know which ABI you are interested in for
> those?
>> I've read through libpkg/pkg_elf.c and I can see how it's reading ELF 
>> headers from well-known files. That's all easy enough to replicate, but 
>> I'm a bit stuck on how it's determining the arch string for x86.
> There are also examples like:
> # pkg config ABI
> FreeBSD:14:armv7
> # pkg config ALTABI
> freebsd:14:armv7:32:el:eabi:hardfp
> Notably, "man 5 pkg.conf" does not even mention ALTABI , just
> ABI .
> Also, only lists the ABI form,
> not the ALTABI form. But it does not mention riscv64 ,
> riscv64sf , any mips64* , any mips* , sparc64 , 
> plain "arm" , armeb , pc98 , ia64 , or alpha at all.
> aarch64 is more like amd64:
> # pkg config ABI
> FreeBSD:14:aarch64
> # pkg config ALTABI
> freebsd:14:aarch64:64
> But I'll note that I used the same machine (without
> rebooting) for both armv7 and aarch64 above: armv7
> was via a chroot and was without qemu involved (qemu
> is not even installed).
> Do you always have a already active execution context
> to work with that is the one of interest, such as being
> in a chroot?
>> How/When does pkg decide to use FreeBSD:13:amd64 instead of 
>> FreeBSD:13:x86:64?
> It might be that it provides ALTABI but makes no use of it?
> That would allow other things to make use of the extra
> information in ALTABI text.
>> Can I safely assume one or the other?
> Likely purpose driven, no universal answer otherwise. You
> may need to indicate what the ABI ( or ALTABI ) strings
> are to be used for.
> It used to be that some of the arm variants could be built
> for either softfloat or hardfloat. Going back further some
> that now have hardfloat instead used a form of softfloat.
> It another example of your not having indicated the limits
> on your range of interest in the possibilities over FreeBSD's
> history.

One thing I know is available is kern.supported_archs :

# sysctl kern.supported_archs
kern.supported_archs: aarch64 armv7

(Also, note the lack of armv6 being listed.
The alternate kernel that I mentioned listed
armv6 instead of armv7. The infrastructure
does not allow for listing both as things are.)

So, using that as a source of ARCH names,


appears to be a valid ABI value on a running system,
and the only valid ABI values for that running system.

I'll note that even when chrooted into a armv7
context on a aarch64 system with AArch32 support:

# sysctl kern.supported_archs
kern.supported_archs: aarch64 armv7

So it does not report specifically on what the chroot
context is for.

Mark Millard
marklmi at