lp://staging/config

Created by Jelmer Vernooij and last modified
Get this branch:
bzr branch lp://staging/config

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
VCS imports
Project:
config
Status:
Development

Import details

Import Status: Suspended

This branch is an import of the HEAD branch of the Git repository at git://git.savannah.gnu.org/config.git.

Last successful import was .

Import started on juju-6c842a-stg-launchpad-codeimport-0 and finished taking 15 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 15 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-3 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-2 and finished taking 15 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 15 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-0 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 15 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-3 and finished taking 10 seconds — see the log

Recent revisions

1253. By John Ericson <email address hidden>

config.sub: Remove windows-gnu

`windows-gnu` has been used by LLVM and Rust to mean MinGW, but many
people on the mailing list object that it is in no way bona fide GNU on
Windows. Even under the interpretation of `-gnu` as a libc which LLVM
often goes with, it doesn't pass muster either because MinGW uses
msvcrt/ucrt, not any GNU libc. Arguably Cygwin, using a modified (GNU)
Newlib, is the closest thing we have to "GNU on Windows" today.

We couldn't decide on what `windows-*` should replace it, or even
whether there should be such a thing, so absent consensus it is better
to just remove it while it is still recently added and we don't need to
worry about backwards compatibility. We can always re-add it later, but
we can't do nothing now and remove it later.

This partially reverts commit 91f6a7f616b161c25ba2001861a40e662e18c4ad.

* config.sub (windows*-gnu*): Remove.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (x86_64-windows-gnu): Remove.

Signed-off-by: Dmitry V. Levin <email address hidden>

1252. By Billy Laws <email address hidden>

config.sub: recognise ARM64EC machine type

ARM64EC is a custom ABI for AArch64 that allows for interoperability
with x86_64 compiled code. While technically just an ABI, it is treated
as its own machine type, with triples in the format arm64ec-*.

* config.sub (arm64ec): Recognize.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (arm64ec-pc-mingw32, arm64ec-windows): New
entries.

Signed-off-by: Dmitry V. Levin <email address hidden>

1251. By Dmitry V. Levin

testsuite: add tests for the aarch64c change

* testsuite/config-guess.data (aarch64c-unknown-freebsd14.0): New entry.
* testsuite/config-sub.data (aarch64c-freebsd14.0,
aarch64c-unknown-freebsd14.0): New entries.

1250. By urs

config.sub: allow aarch64c-unknown-freebsd

config.guess says aarch64c-unknown-freebsd14.0 (cfarm240.cfarm.net,
an Arm Morello SoC, quad-core aarch64 Neoverse N1-based CPU
implementing CHERI), so let config.sub allow it.

* config.sub (aarch64c): Recognize.
* doc/config.sub.1: Regenerate.

Signed-off-by: Dmitry V. Levin <email address hidden>

1249. By Dmitry V. Levin

config.guess: invoke "uname -p" from PATH for non-arm FreeBSD

Starting with commit afe1fa96bf32, "uname -p" from PATH is invoked in
case of FreeBSD on arm, while in other FreeBSD cases it was invoked
using a full pathname as "/usr/bin/uname -p". Fix this inconsistency
and invoke "uname -p" from PATH for all FreeBSD cases. This also allows
to test non-arm FreeBSD cases.

* config.guess (*:FreeBSD:*:*): Invoke "uname -p" from PATH.
* doc/config.guess.1: Regenerate.
* testsuite/config-guess.data (x86_64-unknown-freebsd5.2,
i586-unknown-freebsd7.0): Reintroduce the tests removed by commit
68873f3c11c6.

1248. By Bruno Haible

config.guess: Detect Android (as opposed to GNU/Linux)

Here's a patch to recognize Android environments.

Such environments are "apps" with POSIX-like tools. Today, the most frequently
used one is Termux [1][2][3]; on devices with Android versions before 5.0
one can use Terminal-IDE [4][5].

config.sub already supports this environment:

  $ sh config.sub armv7l-linux-androideabi
  armv7l-unknown-linux-androideabi

I've built many GNU packages in this environment, with the following recipe:
  CONFIG_SHELL=$PREFIX/bin/sh; export CONFIG_SHELL
  CC="clang -ferror-limit=0" CXX="clang++ -ferror-limit=0"; export CC CXX
  ./configure --host=armv7l-linux-androideabi --prefix=$HOME/local

The Termux people have compiled or ported more than 1000 packages as well [6].

But the requirement to pass the --host parameter each time is an annoyance.
Without it, based only on the results of uname, config.guess guesses

  $ sh config.guess
  armv7l-unknown-linux-gnueabi

and many configuration results are wrong (because Android has many functions
in libc without declaring them in the .h files, depending on the so-called
"Android API level"), leading to many compilation errors.

With the attached patch, it produces

  $ sh config.guess
  armv7l-unknown-linux-androideabi

The patch does not include an addition to the config.guess test suite, since
the uname values are:
  $ uname -m
  armv7l
  $ uname -r
  4.19.127
  $ uname -s
  Linux
  $ uname -v
  #1 SMP PREEMPT Tue Apr 4 16:54:58 IST 2023
  $ uname -p
  unknown
which maps to armv7l-unknown-linux-gnueabi.

[1] https://github.com/termux/termux-app
[2] https://f-droid.org/en/packages/com.termux/
[3] https://wiki.termux.com/wiki/Main_Page
[4] https://en.wikibooks.org/wiki/Android/Terminal_IDE
[5] http://www.spartacusrex.com/terminalide.htm
[6] https://github.com/termux/termux-packages/tree/master/packages

* config.guess (Linux|GNU|GNU/*): Detect Android.
* doc/config.guess.1: Regenerate.

Signed-off-by: Dmitry V. Levin <email address hidden>

1247. By Adam Joseph <email address hidden>

config.sub: add javascript-*-ghcjs

GHC has been using a custom triple "javascript-unknown-ghcjs" for
their (non asm.js, non wasm) javascript-emitting kernel-less target.

This triple is a bit of an oddball, so the support for it is highly
restricted in order to discourage further proliferation of the
javascript "cpu" or ghcjs "operating system", which are valid only
in combination with each other.

* config.sub (javascript-*-ghcjs): Allow.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (javascript-ghcjs,
javascript-unknown-ghcjs): New entries.

Link: https://gitlab.haskell.org/ghc/ghc/-/commit/6636b670233522f01d002c9b97827d00289dbf5c
Signed-off-by: Dmitry V. Levin <email address hidden>

1246. By Adam Joseph <email address hidden>

testsuite: add coverage for vendor-clobbering

While reimplementing config.sub for use in a situation where no bash
interpreter was available, I discovered several oddities about
config.sub's behavior.

One such oddity was the fact that an explicitly-provided vendor will
be clobbered by the inferred vendor for three cpu types: microblaze,
s390, and mmix. This commit adds test cases for this clobbering
behavior, so that unintentional changes to it will be noticed.

* testsuite/config-sub.data (microblaze-unknown-elf, mmix-unknown-elf,
s390-unknown-elf): New entries.

Signed-off-by: Dmitry V. Levin <email address hidden>

1245. By John Ericson <email address hidden>

config.sub: Systematize parsing of machine code formats

Instead of treating them as OSes, we treat them as their own category.
This is modeled on what LLVM does with its `ObjectFormatType` enum [1],
advancing my long-running project of trying to nudge GNU config and LLVM
towards each other, taking the best ideas of both.

Currently, my emphasis is just on code cleanup. There are just a few
tests for newly supported changes that fall out of this. But down the
road, this also opens the door to parsing configs with more than 4
components, like [2].

[1]: https://llvm.org/doxygen/classllvm_1_1Triple.html#a83e907e55fa50e093caa96a0aff96201

[2]: https://github.com/llvm/llvm-project/blob/a18266473be1439d324059afa0e8b124f0466428/llvm/unittests/TargetParser/TripleTest.cpp#L1873C50-L1873C77
added in
https://github.com/llvm/llvm-project/commit/28b82bc39ef076527c07718724913f70b5d60b69

* config.sub: Save machine code format name separately from the OS name.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (arm-unknown-none-aout,
arm-unknown-none-pe): New entries.

Signed-off-by: Dmitry V. Levin <email address hidden>

1244. By Maciej W. Rozycki <email address hidden>

config.sub: Handle arbitrary MIPS CPU names

GNU binutils support the selection of the default MIPS subtarget via the
configuration triplet, e.g. `mips64octeon+el-unknown-linux-gnu' builds a
Linux/GNU 64-bit MIPS (n32 ABI) little-endian configuration with the CPU
set to Octeon+ by default. However `config.sub' rejects such a triplet
and indeed it only lets through a random choice of ones people submitted
changes for to support.

There is a large number of MIPS CPU configurations, 118 at the moment,
that GNU binutils know, so rather than adding them individually and then
hoping it will be kept up to date from now on accept any `mips*' pattern
for the machine part, just as we already do for a few of other targets.

 * config.sub: Allow any `mips*' CPU rather than listing a choice
 individually.
 * doc/config.sub.1: Regenerate.
 * testsuite/config-sub.data: Add test cases.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers