DJ Delorie <[email protected]> writes:
> This has come up a few times in the past, and I agree the right
> solution is "don't use them", but popular GNU/Linux distros have
> carried patches in the past (similar to the attached) and people have
> gotten used to them producing *something*, and things broke when the
> patches got dropped. Canonicalizing "it's just -m" might help people
> switch, too.
>
> I am also contemplating an extension to glibc's confstr() that can
> return something more specific than "uname -m" that might be more
> useful but less compatible than past behavior, but I don't know if it
> would make the portability situation better or worse ;-)
>
> The patch only falls back to -m if the user explicitly asked for -p or
> -i, it does not affect -a/-A. It also does not complain if uname()
> fails.
I'd prefer that people just fix the buggy programs that use 'uname -p'.
Some notes on various distributions, since these options have
unfortunately caused me a lot of wasted time.
Various Ubuntu software packages broke when they decided to abandon GNU
coreutils because the package they used to replace it didn't have the
patch they used for GNU coreutils. They plan to remove it in Ubuntu
27.04 [1]. Until then, it gives this annoying output, telling you three
times that you use x86_64 (that also prints a pointer to a variable that
is no longer in scope):
$ gnuuname -a
Linux 3fbca5011dfa 7.3.3-300.fc45.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 6
20:37:28 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Fedora removed their patch 4 years ago [2]. I am not sure if they ran
into any issues because of the behavior change. Here are some related
Red Hat Jira tickets that I haven't looked into much [3][4][5][6].
I don't know if Debian ever used a patch for this behavior. I checked
all Debian versions from Squeeze (2011) to Trixie (2025), and both
options return unknown in all versions, so I don't think they did.
SUSE uses a patch that reads from /proc/cpuinfo for 'uname -p', only on
i686, otherwise, it uses the machine member of struct utsname. It uses
the machine member of struct utsname for 'uname -i' [7]. This leads to a
similar 'uname -a' output to that seen on Ubuntu:
$ uname -a
Linux f959b35856a3 7.3.3-300.fc45.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 6
20:37:28 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Gentoo does something here, probably reading from /proc, but I checked
in a container without the ability to install packages to investigate
further. Also, I don't see any relevant patches for this behavior, which
is confusing [8]:
$ uname -i
AuthenticAMD
$ uname -p
AMD Ryzen 7 3700X 8-Core Processor
I've CC'd Sam James, since he likely knows what the Gentoo version is
doing and can point out something (likely obvious) that I am missing.
It seems that the patches are gradually being dropped.
Collin
[1] https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2150305
[2]
https://src.fedoraproject.org/rpms/coreutils/c/cd953e11dd78cada371f0389171cea671949141b
[3] https://redhat.atlassian.net/browse/RHEL-74146
[4] https://redhat.atlassian.net/browse/RHEL-79768
[5] https://redhat.atlassian.net/browse/RHEL-184885
[6] https://redhat.atlassian.net/browse/RHEL-39739
[7]
https://build.opensuse.org/projects/openSUSE:Factory/packages/coreutils/files/coreutils-sysinfo.patch?expand=1
[8]
https://github.com/gentoo/gentoo/tree/5daa2fa3c472125b5b251a74bb05ba0bca7c4011/sys-apps/coreutils/files
