rucc_sysroot/layout.rs
1//! The directory layout of one target's sysroot, and the cache key that names it.
2//!
3//! Design: `spec/cross-compile/08-sysroots.md` sections 8.2 and 8.3.
4//!
5//! # Why the directories are split the way they are
6//!
7//! Section 8.3 is about a multiplication. Headers are naively `arch x os x libc x libc-version`
8//! trees, which for glibc alone is eight architectures times six versions and several hundred
9//! megabytes, and `spec/cross-compile/13-distribution.md` has a size budget that number destroys.
10//!
11//! The fix is two splits that turn the product into a sum. The per version differences go inside
12//! the files as `#if __GLIBC_MINOR__ >= n`, so one tree serves every version. The per architecture
13//! differences stay in directories, because they are whole files rather than lines, but only for
14//! the small part of a libc that has any: `bits/` and a handful of others. Everything else is one
15//! copy.
16//!
17//! That is why a sysroot here has two include directories rather than one. [`Sysroot::arch_include`]
18//! holds the files that differ by architecture and is searched first, and
19//! [`Sysroot::generic_include`] holds the copy that every architecture shares.
20//!
21//! A Windows target has one rather than two, because mingw-w64's tree is the same files whatever
22//! the machine is and there is nothing for the first directory to hold. That is
23//! [`Sysroot::splits_by_arch`], and the reason it is a question about the target rather than a
24//! directory that happens to be empty is that the compiler prints what it searches.
25//!
26//! A Linux target searches four directories and not two, because the kernel's headers are a second
27//! pair with the same split and a different owner. They are [`Kernel`], their root is the cache
28//! rather than a sysroot, and the order is the libc's two and then the kernel's two, which is the
29//! order `zig cc -E -v` prints for a glibc target. `linux/` and `asm/` are nine megabytes of files
30//! that are the same for every target, so one tree is shared and only `asm/` is copied per
31//! architecture.
32//!
33//! # Why the root is a function of the tuple
34//!
35//! `spec/cross-compile/02-the-goal.md` claim 5 asks for byte identical output from different hosts.
36//! A sysroot that lands in a directory named after the host, or after the day it was built, or
37//! after a hash of an absolute path, breaks that before anything is compiled. So the root is the
38//! cache directory the caller chose plus the canonical spelling of the tuple, and nothing else.
39//!
40//! The canonical spelling is the key rather than a hash of it because it is already unique, it is
41//! already a legal directory name, and a cache a person can read is a cache a person can debug. It
42//! carries the whole ten field model, so `x86_64-linux-gnu` and `x86_64-linux-gnu.2.28` are
43//! different directories, which is the point of `env_version` being in the tuple at all.
44//!
45//! It is not the hash of the contents either, which is what
46//! `spec/cross-compile/13-distribution.md` section 13.2 asked for until tamnd/rucc#1021 settled it.
47//! A name cannot carry one: this function is what the producer calls to find out where to write
48//! files it has not written yet, so there are no contents to hash when the question is asked. The
49//! hash lives in the record instead, which is [`crate::Manifest::digest`], and the one thing the
50//! name has to be is the same on two hosts.
51
52use std::fmt;
53use std::path::{Path, PathBuf};
54
55use rucc_tuple::{Arch, DataModel, Endian, Env, Os, TargetTuple, Version};
56
57/// One target's sysroot: where its headers are, where its link inputs are, and where the record
58/// of what they are is.
59///
60/// Constructed rather than discovered. Nothing here checks that any of these directories exists,
61/// because the caller that is about to produce a sysroot needs the same answer as the caller that
62/// is about to read one, and a constructor that failed for an absent directory would give the
63/// first one nothing to create.
64#[derive(Debug, Clone, PartialEq, Eq)]
65pub struct Sysroot {
66 target: TargetTuple,
67 root: PathBuf,
68 stubs: PathBuf,
69}
70
71impl Sysroot {
72 /// The sysroot for this target inside this cache directory.
73 ///
74 /// The path is `<cache>/sysroots/<canonical tuple>`. Two hosts running this with the same
75 /// cache directory and the same target get the same path, which is what makes the tuple a
76 /// cache key and is the reason `spec/cross-compile/03-target-model.md` section 3.2 admits a
77 /// field only when it changes how a call is made or a struct is laid out.
78 #[must_use]
79 pub fn in_cache(cache: &Path, target: TargetTuple) -> Self {
80 let key = target.to_canonical_string();
81 let root = cache.join("sysroots").join(&key);
82 let stubs = cache.join("stubs").join(&key);
83 Sysroot { target, root, stubs }
84 }
85
86 /// A sysroot rooted at a directory the user named, with `--sysroot` or `-isysroot`.
87 ///
88 /// The layout below the root is the same, so a user who assembled a tree the way we lay one
89 /// out is served by every other method here. A user who did not is served by
90 /// [`Options::sysroot`](crate::Options::sysroot), which replaces step 3 of section 8.5
91 /// wholesale rather than assuming a shape.
92 #[must_use]
93 pub fn at(root: PathBuf, target: TargetTuple) -> Self {
94 let stubs = root.join("lib");
95 Sysroot { target, root, stubs }
96 }
97
98 /// The target this sysroot is for.
99 #[must_use]
100 pub const fn target(&self) -> TargetTuple {
101 self.target
102 }
103
104 /// The directory everything else here is under.
105 #[must_use]
106 pub fn root(&self) -> &Path {
107 &self.root
108 }
109
110 /// The cache key, which is the canonical spelling of the tuple.
111 ///
112 /// The whole tuple and not a summary of it. A key that dropped `env_version` would serve a
113 /// sysroot built against glibc 2.28 to a target that pinned 2.34, and the failure would be a
114 /// missing symbol at link time on one machine and not on another.
115 #[must_use]
116 pub fn cache_key(&self) -> String {
117 self.target.to_canonical_string()
118 }
119
120 /// The headers that differ by architecture, which are searched before the generic ones.
121 ///
122 /// Section 8.3's second split. For musl this is `bits/`, which is a few dozen small files
123 /// against a few hundred shared ones, so the copy per architecture is cheap and the
124 /// alternative of one whole tree per architecture is not.
125 #[must_use]
126 pub fn arch_include(&self) -> PathBuf {
127 self.root.join("include").join(self.header_arch())
128 }
129
130 /// The headers every architecture shares, which is almost all of them.
131 #[must_use]
132 pub fn generic_include(&self) -> PathBuf {
133 self.root.join("include").join("generic")
134 }
135
136 /// The libc's include directories, in search order, most specific first.
137 ///
138 /// Two rather than four. A Linux target also needs the kernel's own headers, which are
139 /// [`Kernel`] and are not under this root, because they are the same files for every target
140 /// that shares an architecture and carrying a copy of them per tuple is nine megabytes times
141 /// the size of the table.
142 ///
143 /// One rather than two for a Windows target, which is [`Sysroot::splits_by_arch`].
144 #[must_use]
145 pub fn includes(&self) -> Vec<PathBuf> {
146 if self.splits_by_arch() {
147 vec![self.arch_include(), self.generic_include()]
148 } else {
149 vec![self.generic_include()]
150 }
151 }
152
153 /// Whether this target's headers are split by architecture at all.
154 ///
155 /// Section 8.3's second split is a libc's, and mingw-w64 has not got one. Measured rather than
156 /// assumed: installing mingw-w64 14.0.0's headers for `x86_64-w64-mingw32`,
157 /// `i686-w64-mingw32` and `aarch64-w64-mingw32` gives three trees of 1702 files that `diff -rq`
158 /// finds no difference between, because what a Windows header would branch on is the API level
159 /// the program asked for with `_WIN32_WINNT` rather than the machine it is being compiled for.
160 ///
161 /// So a Windows sysroot has `include/generic` and nothing beside it, and this is what keeps the
162 /// search path from naming a directory that a producer was never going to write. A path that is
163 /// simply absent would cost nothing at lookup time, which is why this is about honesty rather
164 /// than about speed: `-print-search-dirs` and `-E -v` print what is searched, and a directory
165 /// nobody publishes is a line that sends a person looking for a tree that does not exist.
166 #[must_use]
167 pub fn splits_by_arch(&self) -> bool {
168 self.target.os() != Os::Windows
169 }
170
171 /// The link inputs: the start files, the libc archive or its generated stubs, and the
172 /// compiler's own runtime for this target.
173 #[must_use]
174 pub fn lib(&self) -> PathBuf {
175 self.root.join("lib")
176 }
177
178 /// Where the stub libraries a glibc link reads are, which is `<cache>/stubs/<canonical tuple>`
179 /// for a sysroot in the cache and [`Sysroot::lib`] for one the user named.
180 ///
181 /// Beside the sysroot rather than inside it, because the sysroot is a fetched archive whose
182 /// every file is in its manifest with a hash, and the stubs are written by the compiler out of
183 /// the description it carries, so they would be files the manifest does not know about. A tree
184 /// somebody assembled has its own `libc.so`, and that is where it is.
185 ///
186 /// The same key as the sysroot, release included, because a stub cut at glibc 2.28 and one cut
187 /// at 2.39 are different files and a program linked against the wrong one either runs on a
188 /// machine it should not or refuses one it could.
189 #[must_use]
190 pub fn stubs(&self) -> &Path {
191 &self.stubs
192 }
193
194 /// The manifest naming every input with its source, its hash and its licence.
195 ///
196 /// A file rather than a directory, and at the top rather than beside the libraries, because
197 /// the thing a person does with it is read it first.
198 #[must_use]
199 pub fn manifest_path(&self) -> PathBuf {
200 self.root.join("manifest")
201 }
202
203 /// The name the target's libc gives to its per architecture header directory.
204 ///
205 /// Not the architecture component of the canonical tuple, which carries a baseline the headers
206 /// do not care about: `armv7a-linux-musleabihf` and `armv5te-linux-musleabi` read the same
207 /// `arm` directory, because a header does not know which instructions the chip has. 32-bit x86
208 /// is `i386` in musl's source tree whatever the tuple spells it.
209 ///
210 /// # Why the libc is part of the answer
211 ///
212 /// The two libcs do not split their headers at the same place, and the name has to follow the
213 /// libc rather than a scheme of ours, because the producer installs what the libc's own build
214 /// system installs and the compiler has to look where that put it.
215 ///
216 /// musl splits per architecture and per ABI, which is what `arch/` in its source tree is, so
217 /// `x86_64`, `i386` and `x32` are three directories. glibc splits per architecture family and
218 /// handles the rest inside the files: one `x86` directory serves i386, x86-64 and x32, and 22
219 /// of the 31 files in its `bits/` branch on `__x86_64__`, `__ILP32__` or `__WORDSIZE` to do it,
220 /// starting with `bits/wordsize.h`. Checked against Zig 0.16, which ships twelve glibc
221 /// directories named after families and seventeen musl directories named after architectures.
222 ///
223 /// # The rule this is here to enforce
224 ///
225 /// An ILP32 ABI on a 64-bit architecture cannot read the LP64 headers. Every type that carries
226 /// a pointer or a `long` is a different size, and `x86_64-linux-gnux32` is the row that proves
227 /// it. For musl that is a separate directory, which is what the suffix below is. For glibc it
228 /// is a branch inside glibc's own files, so the directory is shared and the thing that checks
229 /// it is section 8.4's structural equivalence corpus rather than a path.
230 #[must_use]
231 pub fn header_arch(&self) -> &'static str {
232 if self.target.env() == Env::Gnu {
233 return self.header_family();
234 }
235 let narrow = self.target.data_model() == DataModel::Ilp32On64;
236 match (self.target.arch(), narrow) {
237 // x32 is what everyone calls it, including musl and glibc, so it does not get the
238 // suffix the rule below would give it.
239 (Arch::X86_64, true) => "x32",
240 (Arch::X86_64, false) => "x86_64",
241 (Arch::X86, _) => "i386",
242 (Arch::Aarch64 | Arch::Arm64Ec, true) => "aarch64_ilp32",
243 (Arch::Aarch64 | Arch::Arm64Ec, false) => "aarch64",
244 (Arch::Arm, _) => "arm",
245 (Arch::Riscv64, true) => "riscv64_ilp32",
246 (Arch::Riscv64, false) => "riscv64",
247 (Arch::Riscv32, _) => "riscv32",
248 (Arch::S390x, true) => "s390x_ilp32",
249 (Arch::S390x, false) => "s390x",
250 (Arch::PowerPc64, true) => "powerpc64_ilp32",
251 (Arch::PowerPc64, false) => "powerpc64",
252 (Arch::LoongArch64, true) => "loongarch64_ilp32",
253 (Arch::LoongArch64, false) => "loongarch64",
254 (Arch::Wasm32, _) => "wasm32",
255 }
256 }
257
258 /// The architecture family, which is how glibc names its per architecture header directory.
259 ///
260 /// The data model is not in it, on purpose, for the reason [`Sysroot::header_arch`] gives: the
261 /// family's files carry the branch themselves. `s390x` and `loongarch` are spelled the way
262 /// glibc's own `sysdeps` tree spells them, which is not the same shortening for both.
263 ///
264 /// # Why powerpc is the only family whose byte order is in the name
265 ///
266 /// The byte order is in the name exactly where the installed text depends on it, and that is one
267 /// family. Measured on glibc 2.44, by installing a family's headers twice with
268 /// `make install-headers` and diffing the two installs. `aarch64_be-linux-gnu` against
269 /// `aarch64-linux-gnu` is 474 files each and an empty diff, so one directory serves both orders.
270 /// `powerpc64-linux-gnu` against `powerpc64le-linux-gnu` is 474 files each and one file that
271 /// differs, `bits/long-double.h`, because little endian powerpc can redirect `long double` to
272 /// the float128 ABI and big endian powerpc cannot, so one install defines
273 /// `__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI` as `(__LDBL_MANT_DIG__ == 113)` and the other defines
274 /// it as `0`. One directory for both orders would hand half of the powerpc rows a macro that is
275 /// wrong about their own ABI.
276 ///
277 /// The word size is not in the name, for powerpc either. The third run of the same experiment,
278 /// `powerpc-linux-gnu` against `powerpc64-linux-gnu` with the order held fixed, is 474 files
279 /// each and an empty diff, which is the x86 answer again: `bits/wordsize.h` is two files in
280 /// glibc's `sysdeps` tree for powerpc and they are byte identical, and both of them branch on
281 /// `__powerpc64__`. So the name is the family and the order and nothing else, which is why it is
282 /// `powerpc` and `powerpcle` rather than a spelling per width.
283 ///
284 /// `bits/endianness.h` is not the reason, which is worth saying because it reads like the
285 /// obvious one and tamnd/rucc#940 was written around it. glibc's copies of that file for arm,
286 /// aarch64 and powerpc branch on `__BIG_ENDIAN__` and `_BIG_ENDIAN` inside the file, the same
287 /// way `bits/wordsize.h` branches on `__x86_64__`, so both orders install the same text into it.
288 /// musl 1.2.5 does the same in `bits/alltypes.h` and `bits/signal.h` and ships no per order
289 /// directory under `arch/` at all, which is why [`Sysroot::header_arch`]'s musl names carry no
290 /// order either.
291 fn header_family(&self) -> &'static str {
292 match (self.target.arch(), self.target.endian()) {
293 (Arch::X86_64 | Arch::X86, _) => "x86",
294 // Arm64EC is a Windows ABI and never has glibc headers. It answers with the family it
295 // belongs to rather than with a word that is not a directory anywhere.
296 (Arch::Aarch64 | Arch::Arm64Ec, _) => "aarch64",
297 (Arch::Arm, _) => "arm",
298 (Arch::Riscv64 | Arch::Riscv32, _) => "riscv",
299 (Arch::S390x, _) => "s390x",
300 // `powerpc` is the big endian directory because that is the name glibc's own `sysdeps`
301 // tree uses and big endian is what the bare spelling means everywhere in this tuple
302 // model. `powerpcle` is the GNU spelling of the other one.
303 (Arch::PowerPc64, Endian::Big) => "powerpc",
304 (Arch::PowerPc64, Endian::Little) => "powerpcle",
305 (Arch::LoongArch64, _) => "loongarch",
306 // There is no glibc for wasm. The arm of the match exists because the type is closed
307 // and a wildcard here would quietly name a directory for a future architecture.
308 (Arch::Wasm32, _) => "wasm32",
309 }
310 }
311}
312
313/// The kernel's own headers, which are not the libc's and are shared by every target that can read
314/// them.
315///
316/// `linux/` and `asm/` are the system call interface rather than the C library, and a sysroot
317/// without them does not compile 31 of glibc's installed headers or 3 of musl's, `sys/quota.h` and
318/// `net/ethernet.h` among them. So they are part of what section 8.2 calls a sysroot even though no
319/// libc produced them.
320///
321/// # Why they are not under [`Sysroot`]
322///
323/// One tree serves every libc and every architecture except `asm/`, which is per architecture and
324/// small. Copying the shared part into each tuple's sysroot would be nine megabytes times the
325/// number of Linux rows in the table, for files that are identical in every copy. So the root is
326/// the cache directory rather than a sysroot, and a sysroot that was produced with it records the
327/// version in its manifest, which is [`crate::Manifest::kernel`] and the `kernel` line of the
328/// format. The tree carries its own record as well, headed `rucc kernel headers manifest 1`, because
329/// one tree serves every target and a sysroot manifest names one. Nothing checks the two against
330/// each other: a sysroot can be produced beside one tree and read beside another, and the manifest
331/// makes that visible rather than preventing it.
332///
333/// # Why the version is not in the path
334///
335/// The driver has to be able to compute this path before it reads anything, and a version in the
336/// path would mean asking the cache what it has before being able to ask where it is. It is the
337/// same decision [`Sysroot::in_cache`] makes about the libc version, where the tuple carries the
338/// version only because `env_version` is part of the target's identity, and the same gap: a cache
339/// populated by one release and read by the next gets whatever is there.
340///
341/// That gap does not close by putting a hash in a path, which is what
342/// `spec/cross-compile/13-distribution.md` section 13.2 used to say and what tamnd/rucc#1021
343/// settled: a path has to be known before anything has been read. What closes it is comparing a
344/// record against one somebody published, and the record says which release it was, here as the
345/// tree's own `manifest` and in a sysroot as [`crate::Manifest::kernel`].
346#[derive(Debug, Clone, PartialEq, Eq)]
347pub struct Kernel {
348 arch: &'static str,
349 root: PathBuf,
350}
351
352impl Kernel {
353 /// The kernel headers in this cache directory for this target, when the target has any.
354 ///
355 /// [`None`] for everything that is not Linux with a libc we produce a tree for. Windows, the
356 /// BSDs and Darwin have their own system headers and no `linux/` at all, freestanding has no
357 /// system call interface by definition, and Android is Linux but bionic carries its own
358 /// scrubbed copy of the uapi headers, which is a different tree from this one and not a subset
359 /// of it.
360 #[must_use]
361 pub fn for_target(cache: &Path, target: TargetTuple) -> Option<Kernel> {
362 if target.os() != Os::Linux || !matches!(target.env(), Env::Gnu | Env::Musl) {
363 return None;
364 }
365 let arch = kernel_arch(target.arch())?;
366 Some(Kernel { arch, root: Kernel::in_cache(cache) })
367 }
368
369 /// Where the tree is under a cache directory, whichever target is asking.
370 ///
371 /// Separate from [`Kernel::for_target`] because an install puts the whole tree there and has no
372 /// target to ask with, and one place that spells the name is one place it can be wrong.
373 #[must_use]
374 pub fn in_cache(cache: &Path) -> PathBuf {
375 cache.join("kernel-headers")
376 }
377
378 /// The directory both of these are under.
379 #[must_use]
380 pub fn root(&self) -> &Path {
381 &self.root
382 }
383
384 /// `asm/`, which is the part of the interface that is per architecture.
385 ///
386 /// Named after the kernel's own architecture directory and not after ours or the libc's, which
387 /// is a third spelling of the same machine and the reason this is a method rather than a format
388 /// string at the call site.
389 #[must_use]
390 pub fn arch_include(&self) -> PathBuf {
391 self.root.join(self.arch)
392 }
393
394 /// `linux/`, `asm-generic/` and the rest, which are the same files for every architecture.
395 #[must_use]
396 pub fn generic_include(&self) -> PathBuf {
397 self.root.join("generic")
398 }
399
400 /// Both directories, in search order, most specific first.
401 #[must_use]
402 pub fn includes(&self) -> Vec<PathBuf> {
403 vec![self.arch_include(), self.generic_include()]
404 }
405
406 /// The kernel's name for this architecture.
407 #[must_use]
408 pub const fn arch(&self) -> &'static str {
409 self.arch
410 }
411}
412
413/// What `make headers_install ARCH=` takes, which is a third naming of the machine.
414///
415/// `arm64` rather than `aarch64` and `s390` rather than `s390x`, because those are the directories
416/// under `arch/` in the kernel's source tree, and the 31-bit s390 port leaving did not rename the
417/// one that stayed. One directory serves both widths of x86, of riscv and of powerpc, the same way
418/// glibc's family does and for the same reason: the uapi headers branch on the compiler's macros.
419///
420/// [`None`] for an architecture the kernel does not have, which is wasm.
421const fn kernel_arch(arch: Arch) -> Option<&'static str> {
422 match arch {
423 Arch::X86_64 | Arch::X86 => Some("x86"),
424 Arch::Aarch64 | Arch::Arm64Ec => Some("arm64"),
425 Arch::Arm => Some("arm"),
426 Arch::Riscv64 | Arch::Riscv32 => Some("riscv"),
427 Arch::S390x => Some("s390"),
428 Arch::PowerPc64 => Some("powerpc"),
429 Arch::LoongArch64 => Some("loongarch"),
430 Arch::Wasm32 => None,
431 }
432}
433
434/// Whether we can produce a sysroot for this target without the user fetching anything.
435///
436/// Section 8.2's table has seven rows and two of them are legal walls rather than engineering.
437/// The macOS SDK is restricted by the Xcode licence to Apple-branded hardware and the Windows SDK
438/// is not redistributable, so for those two the answer is a path the user supplies under their own
439/// licence, and `spec/cross-compile/13-distribution.md` owns the mechanism.
440///
441/// This returns false for those two and true for everything else, including freestanding, which
442/// needs nine compiler headers and no link inputs at all.
443///
444/// Which of the two walls a target is behind is [`crate::Wall`], and this is that question asked
445/// without caring about the answer. One of them is a predicate a producer filters a table with and
446/// the other is what a message has to say, and they are the same rule either way round.
447#[must_use]
448pub fn can_be_bundled(target: TargetTuple) -> bool {
449 crate::Wall::of(target).is_none()
450}
451
452/// The glibc our bundled header tree is derived from.
453///
454/// A fact about the tree and not a choice. `sysroots/manifest` in `tamnd/rucc-cross` pins the glibc
455/// source by version and hash, the tree is produced from that source, and this is that version. It
456/// moves when the pin moves and the two are checked against each other by the producer.
457pub const BUNDLED_GLIBC: Version = Version::new(2, 44);
458
459/// The `__GLIBC_MINOR__` a target gets when it is compiled against the bundled glibc tree.
460///
461/// Design: `spec/cross-compile/08-sysroots.md` section 8.3.
462///
463/// One tree serves every glibc release, with the differences written inside the files as
464/// `#if __GLIBC_MINOR__ >= n`, so the release is the part of it the target supplies. That is Zig's
465/// patch to the same tree and the same macro, which is where the spelling comes from: `features.h`
466/// keeps `__GLIBC__` at 2 and leaves the minor to the compiler, and `__GLIBC_PREREQ` reads both.
467///
468/// [`None`] for anything that is not glibc, because there is no such macro on musl or mingw and
469/// defining one would have every probe for it answer yes on a libc that does not have it.
470///
471/// The version is the one the tuple asked for, which is the point of `env_version` being in the
472/// tuple, and [`BUNDLED_GLIBC`] when it asked for nothing. Asking for an older release is how a
473/// program is kept off symbols and declarations the target's libc does not have, and it is honest
474/// only as far as the text goes: the declarations are guarded by the macro and the structure
475/// layouts in the same files are one release's. Issue #926's last box is where that is finished and
476/// it is the same direction as the compat symbol gap of #920, too permissive rather than wrong
477/// about what it does say.
478///
479/// # Errors
480///
481/// A release newer than the tree, which is the one direction that cannot be approximated. Every
482/// `__GLIBC_PREREQ` in the program would answer yes and the declarations behind them would not be
483/// there, so the failure would be a missing declaration at best and a missing symbol at link time
484/// at worst. Both versions are in the error, because the two things a person can do about it are
485/// pin a release the tree has and name a sysroot that has the one they asked for, and neither is a
486/// choice they can make without being told which release the tree is.
487pub fn bundled_glibc_minor(target: TargetTuple) -> Result<Option<u32>, GlibcSkew> {
488 if target.os() != Os::Linux || target.env() != Env::Gnu {
489 return Ok(None);
490 }
491 let Some(asked) = target.env_version() else {
492 return Ok(Some(BUNDLED_GLIBC.minor_part().unwrap_or(0)));
493 };
494 // A glibc version is two components and a tuple will hold one or three, so a request this
495 // cannot read as a glibc release is a request for the tree's own version rather than an error:
496 // `gnu.2` is somebody naming the libc and not pinning it.
497 let Some(minor) = asked.minor_part() else {
498 return Ok(Some(BUNDLED_GLIBC.minor_part().unwrap_or(0)));
499 };
500 if asked.major_part() != BUNDLED_GLIBC.major_part()
501 || minor > BUNDLED_GLIBC.minor_part().unwrap_or(0)
502 {
503 return Err(GlibcSkew { asked, tree: BUNDLED_GLIBC });
504 }
505 Ok(Some(minor))
506}
507
508/// A glibc release the bundled tree cannot serve, and the release the tree is.
509///
510/// A type rather than a pair, because the two versions read the same way round in the message as
511/// they do here and a caller that swapped them would produce a diagnostic exactly as wrong as it is
512/// convincing.
513#[derive(Debug, Clone, Copy, PartialEq, Eq)]
514pub struct GlibcSkew {
515 /// What the target asked for.
516 pub asked: Version,
517 /// What the bundled tree is, which is [`BUNDLED_GLIBC`].
518 pub tree: Version,
519}
520
521impl fmt::Display for GlibcSkew {
522 fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
523 write!(
524 f,
525 "the target asked for glibc {}, and the bundled headers are glibc {}",
526 self.asked, self.tree
527 )
528 }
529}
530
531impl std::error::Error for GlibcSkew {}