tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1430Shell 145Markdown 87Rust 852973 Sutichaykuna

⎇ 87b6c3020a5285cf1d41ccdf1c8070b53adbcb98 recipes/rust-alpine-target.patch 84 siq'ikuna · 4.6 KB Ñawpa willay ch'uya

el enlazador va DENTRO del compilador — `/etc/cargo/config.toml` es una ruta que cargo no lee e903f486d · Sergio ·

1Registra el triple de Alpine `x86_64-alpine-linux-musl` como target de rustc.
2
3POR QUÉ (SDD 31 §4.bis). El build usa el triple de Alpine en todas partes porque el stage0 es el
4rustc del LAB y Alpine RENOMBRA su triple: con el canónico, el stage0 no tiene la std
5(`can't find crate for std`). Pero ese nombre lo conoce el rustc de Alpine y NO el de upstream, así
6que en el stage 2 —cuando toma el relevo el compilador que acabamos de construir— el build muere:
7
8    error: error loading target specification: could not find specification for target
9           "x86_64-alpine-linux-musl"
10
11O sea: el triple que hace falta para ARRANCAR el build es el que el PRODUCTO del build no tiene.
12Esto lo mete DENTRO del compilador, que es lo que hace Alpine en su APKBUILD, y por eso vale en
13todos los stages (un `.json` por `RUST_TARGET_PATH` no sirve para el triple del HOST).
14
15La única diferencia real con el spec canónico es `crt_static_default = false`: es lo que habilita
16dylibs y, con ellos, los PROC-MACROS. Un rustc con `crt-static` por default no puede compilar
17`serde_derive` ni `clap_derive` — ni las 44 recetas `cargo-*` del corpus que usan `derive`.
18
19--- /dev/null
20+++ b/compiler/rustc_target/src/spec/targets/x86_64_alpine_linux_musl.rs
21@@ -0,0 +1,53 @@
22+use crate::spec::{
23+    Arch, Cc, LinkerFlavor, Lld, SanitizerSet, StackProbeType, Target, TargetMetadata, base,
24+};
25+
26+pub(crate) fn target() -> Target {
27+    let mut base = base::linux_musl::opts();
28+    base.cpu = "x86-64".into();
29+    base.plt_by_default = false;
30+    base.max_atomic_width = Some(64);
31+    base.add_pre_link_args(LinkerFlavor::Gnu(Cc::Yes, Lld::No), &["-m64"]);
32+    base.stack_probes = StackProbeType::Inline;
33+    base.static_position_independent_executables = true;
34+    base.supported_sanitizers = SanitizerSet::ADDRESS
35+        | SanitizerSet::CFI
36+        | SanitizerSet::LEAK
37+        | SanitizerSet::MEMORY
38+        | SanitizerSet::THREAD;
39+    base.supports_xray = true;
40+    // ── ESTÁTICO POR DEFECTO, PERO CON DYLIBS ─────────────────────────────────────────────────
41+    // `crt_static_default = true` es lo que hace que un `rustc hola.rs` produzca un binario que
42+    // CORRE en una caja takana: sin él, rustc enlaza dinámico y pide `-lgcc`, que no existe —la
43+    // distro se construye con zig, que trae compiler-rt—, y el enlace muere en `cannot find -lgcc`.
44+    // `crt_static_allows_dylibs = true` es su pareja obligatoria: sin ella, `crt-static` apaga los
45+    // dylibs y con ellos los PROC-MACROS (`serde_derive`, `clap_derive` y las 44 recetas `cargo-*`
46+    // del corpus que usan `derive`). Los dos juntos = binarios estáticos y proc-macros vivos.
47+    // El compilador EN SÍ sigue siendo dinámico: el `bootstrap.toml` fija `crt-static = false` para
48+    // el build, que gana sobre este default.
49+    base.crt_static_default = true;
50+    base.crt_static_allows_dylibs = true;
51+
52+    // ── EL ENLAZADOR, EN EL COMPILADOR Y NO EN UN FICHERO DE CONFIG ───────────────────────────
53+    // Sin esto, `rustc` busca `cc` —que una caja takana NO TIENE— y falla con `linker \`cc\` not
54+    // found`. Ponerlo acá y no en un `config.toml` de cargo es la diferencia entre «takana compila
55+    // Rust» y «takana compila Rust si sabés tres flags»: el que compila es rustc, y rustc no lee la
56+    // config de cargo. `ld.lld` lo publica `recipes/lld21.toml`, que va en el mismo perfil.
57+    base.linker = Some("ld.lld".into());
58+    base.linker_flavor = LinkerFlavor::Gnu(Cc::No, Lld::Yes);
59+
60+    Target {
61+        llvm_target: "x86_64-alpine-linux-musl".into(),
62+        metadata: TargetMetadata {
63+            description: Some("64-bit Alpine Linux with musl (triple propio de Alpine)".into()),
64+            tier: Some(3),
65+            host_tools: Some(true),
66+            std: Some(true),
67+        },
68+        pointer_width: 64,
69+        data_layout:
70+            "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128".into(),
71+        arch: Arch::X86_64,
72+        options: base,
73+    }
74+}
75--- a/compiler/rustc_target/src/spec/mod.rs
76+++ b/compiler/rustc_target/src/spec/mod.rs
77@@ -1506,6 +1506,7 @@
78     ("aarch64-unknown-linux-musl", aarch64_unknown_linux_musl),
79     ("aarch64_be-unknown-linux-musl", aarch64_be_unknown_linux_musl),
80     ("x86_64-unknown-linux-musl", x86_64_unknown_linux_musl),
81+    ("x86_64-alpine-linux-musl", x86_64_alpine_linux_musl),
82     ("i686-unknown-linux-musl", i686_unknown_linux_musl),
83     ("i586-unknown-linux-musl", i586_unknown_linux_musl),
84     ("mips-unknown-linux-musl", mips_unknown_linux_musl),