-static-libstdc++ is for portable prebuilt binaries. A build against
system libraries should use the shared libstdc++ like any other distro
package, and Fedora does not even ship the static archive by default.
dpkg-buildflags now adds -Wl,--package-metadata=<url-encoded JSON>,
which ConfigParser rejects under its default interpolation. Machine
files are not interpolated, so turn it off.
The generic ARM flags name armv5t, which has neither Thumb-2 nor the
divide a Cortex-A7 has, and nothing took the float out of the ABI.
Clang also wants the eabi environment rather than elf.
The flavor is detected from the driver's own linker, which on macOS
is Apple's, while a bare-metal target links with LLD. LLD refuses
the option, so every link probe fails and each feature behind one
is detected as missing.
Read the config as a set of tags, thus a bare flavor says in its name
whether its code is position-independent: softfloat becomes
softfloat_nopic, and softfloat_msabi becomes softfloat_pic_msabi. This
also gives x86 a position-independent flavor, which it had no way to
name before.
A bare target is soft-float in each case now, thus remove the newlib
path that the other targets took.
The SDK that would have supplied a compiler is what is being built,
so either a triplet names the toolchain or the tools are named
outright. "No C compiler found" on a box full of them helps nobody.
The one we had suits a Linux module: System V, and not position
independent — the module loader resolves no GOT relocation, and the
kernel code model expects the top 2GB. A Windows kernel follows
another convention, and the agent's text is mapped a second time
into each instrumented process, shared, so that flavor is position
independent instead.
Soft float is what kernel mode means rather than what either
convention says, so both carry it. The convention is a property of
the machine rather than the toolchain, so it rides in the machine
file for whoever generates or inspects the code.
Everything in it is built -fno-pic, so a distribution whose driver
defaults to PIE rejects the resulting R_386_32 relocations outright.
Only 32-bit x86 minds, its addressing having nowhere else to go.
Straight to the linker: clang swallows the driver spelling when it is
gcc doing the link.
Share the soft-float flags both x86 bitnesses need and keep the
64-bit-only ones — the red zone, the kernel code model and the IBT
pair — with x86_64. clang has no i386 bare-metal triple under the
arch's own name, so map it to i686, and skip the hard-float arch
flags, which -mfpmath=sse would contradict.
A jump table is reached by an indirect jump, which the compiler marks
notrack and an IBT kernel does not permit, having left NOTRACK_EN clear.
Its own C is compiled this way for the same reason.
Soft-float on x86_64 is LLVM's +soft-float feature, which is what Rust's
own x86_64-unknown-none turns on, so both halves of a kernel-mode build
agree on where a double travels. -mno-sse alone does not reach the ABI.
long double has to be narrowed as well: soft-float has no lowering for
x87's 80-bit format, and LLVM crashes selecting it.
Only clang's bare-metal driver searches the sysroot on its own, and it
picks that driver for arm64 but not for x86_64, hence spelling out both
paths.
picolibc leaves stdout and the heap bounds to the environment, so every
configure check that touched stdio or malloc failed on those instead of
on what it was checking.
The none-arm64-softfloat flavour has no C library of its own: newlib has
no soft-float build for arm64, so it borrows one assembled by hand. Add
picolibc and compiler-rt as packages instead.
Both are needed before anything else compiles, since the toolchain finds
their headers through --sysroot, so the packages that would otherwise
have no dependencies gain one. Under -mabi=aapcs-soft a double is passed
in x0, and picking up a runtime that expects d0 makes every helper the C
library calls return nonsense without failing.
Bump libffi for the matching x18 fix.
Passing floats in general-purpose registers is an ABI break, so it earns
a config rather than a build option. It drags -ffixed-x18 and -fno-pic
along because the first host needing it is the Linux arm64 kernel, which
reserves x18 and whose module loader rejects GOT relocations. newlib's
syscall stubs are dropped: this flavour brings picolibc instead.
The per-machine /I and /LIBPATH flags only reach the host compiler. A
native build's build-machine compiler, used for native targets like the
resource compiler, still needs INCLUDE/LIB from the environment, which
spans both machines.
Header and library search paths went into INCLUDE/LIB, which can only
hold one toolchain and thus broke arm64<->x64 cross builds. Emit them
as per-machine /I and /LIBPATH flags, which MSVC searches first.
Allow overriding the Apple deployment-target floor at configure
time without editing env_apple.py — e.g., to raise macOS to
15+ for the Apple-native gioapple TLS backend.
Pass --with-apple-min-os=PLATFORM=VERSION once per platform to
override (PLATFORM being a key in APPLE_MINIMUM_OS_VERSIONS).
Precedence: explicit os-dash-arch entry > explicit OS entry >
os-dash-arch default > OS default.
When Swift's clang.exe is found by env2mfile on Windows instead of
cl.exe, detect_linker_flavor() invokes it with `-Wl,--version`, which
produces only link.exe's LNK4044 warning and no recognisable version
banner, causing LinkerDetectionError to propagate out of
init_machine_config().
Catch the exception and fall through to the winenv.detect_msvs_tool_path
path, which correctly locates cl.exe/link.exe for the target machine.
If we use LLD with GCC, then `gcc -Wl,--version` outputs something like:
collect2 version 13.3.0
[ ... ]
LLD 18.0.3 (compatible with GNU linkers)
which is not currently matched in env_generic.py. To fix it, look for
the "compatible with GNU linkers" substring as well.
