On Monday, April 7th, 2025 at 3:53 PM, Zack Weinberg <z...@owlfolio.org> wrote:
> On Sat, Apr 5, 2025, at 7:38 AM, sin-ack via Patches for the config.guess and
> config.sub scripts wrote:
> ...
>
> > Setting the vendor to "android" lets us tell the software that even
> > though the GNU ABI is in effect, certain restrictions are present due
> > to running on Android.
>
>
> Please don't use the vendor field for this. The vendor field is a
> vestige of a forgotten era of bad marketing choices by 1980s Unix
> workstation companies. There's a lot of software out there that isn't
> prepared for it to have a value they need to pay attention to. As a
> matter of policy I think GNU should be moving toward a world where the
> vendor field is always "unknown" except in the (now retrocomputing-
> only) cases where it's actually doing some disambiguation work
> (e.g. `m88k-{motorola,dolphin,tektronix}-sysv3` - yes, you read
> that right, System V Release 3 variants).
>
> Instead, please use the ABI field: `<cpu>-unknown-linux-android` instead of
>
> `<cpu>-unknown-linux-gnu`. The seccomp restrictions you describe are a big
>
> enough deal to call it an entirely new ABI.
There already exists a *-unknown-linux-android ABI, which is for
compiling against the Android NDK. What I am trying to achieve is a
target where we are using GNU everything, but still abiding by these
seccomp restrictions. Therefore, it would have to be something like
*-unknown-linux-gnuandroid. My main concern with introducing this was
that it would break basically every piece of software out there that
relies on checking -linux-gnu to configure itself, and the amount of
patches required to deal with the fallout compared to the amount of
deviation from the standard GNU userspace which is miniscule.
How do you recommend proceeding forward? Should I create a new ABI
kind regardless?
