meson and cmake both ask the HOST where libraries go. On Ubuntu the
answer is lib/s390x-linux-gnu, so five packages already in the repository
ship theirs where Arch's ld.so and pkgconf never look. Measured:
expat 12 lz4 6 pacman 6 pkgconf 6 zstd 12 entries
Nothing failed. util-linux is where it finally shouted, and even there
the rm was the first victim, not the cause.
pacman is the one that matters: libalpm.so.16 landed where pacman's own
binary cannot load it, and a target installed from that package has no
working package manager left to repair itself with.
arch-meson now states the libdir devtools has no need to state, and is
reinstalled on every run -- editing the copy here changed nothing while
/usr/local/bin held a stale one. Four packages call bare meson or cmake
and get their own hook. util-linux's old hook chased lib64, which never
existed here; it is deleted.
--- FR ---
meson et cmake demandent tous deux à l'HÔTE où vont les bibliothèques.
Sous Ubuntu la réponse est lib/s390x-linux-gnu : cinq paquets déjà dans
le dépôt livrent donc les leurs là où ld.so et pkgconf d'Arch ne
regarderont jamais. Mesuré :
expat 12 lz4 6 pacman 6 pkgconf 6 zstd 12 entrées
Rien n'a échoué. util-linux est l'endroit où cela a fini par crier, et
même là le rm était la première victime, pas la cause.
pacman est celui qui compte : libalpm.so.16 atterrissait là où le binaire
de pacman ne peut pas la charger, et une cible installée depuis ce paquet
n'a plus de gestionnaire de paquets pour se réparer.
arch-meson énonce désormais le libdir que devtools n'a pas besoin
d'énoncer, et se réinstalle à chaque exécution : éditer la copie du dépôt
ne changeait rien tant que /usr/local/bin en gardait une périmée. Quatre
paquets appellent meson ou cmake nu et reçoivent leur crochet. L'ancien
crochet util-linux poursuivait un lib64 qui n'a jamais existé ici : il
est supprimé.
Assisted-by: Claude Opus 5
libselinux does not exist in Arch, so its clone 404'd. GitLab answers a
404 by asking for credentials, which is why the log read "could not read
Username" rather than "no such project" -- the first wrong culprit.
The second was mine. Neither the clone nor the cd that follows it was
guarded, so makepkg ran in whatever directory the previous package had
left. It rebuilt util-linux, wrote 119 KB of util-linux output into
log-libselinux.txt, and copied the artefact back into the repository.
The lesson is the repository's oldest one, one level up: an exit code
proves nothing, and neither does a log file's name. Verified by checking
every log against the "==> Making package:" line inside it.
--- FR ---
libselinux n'existe pas dans Arch, son clone a donc rendu un 404. GitLab
répond à un 404 en réclamant des identifiants : d'où le « could not read
Username » du journal, plutôt qu'un « projet inconnu ». Premier faux
coupable.
Le second était de mon fait. Ni le clone ni le cd qui le suit n'étaient
gardés, alors makepkg tournait dans le répertoire laissé par le paquet
précédent. Il a reconstruit util-linux, versé 119 ko de sortie util-linux
dans log-libselinux.txt, puis recopié l'artefact dans le dépôt.
La leçon est la plus ancienne du dépôt, d'un cran plus haut : un code de
sortie ne prouve rien, et le NOM d'un journal non plus. Vérifié en
confrontant chaque journal à la ligne « ==> Making package: » qu'il porte.
Assisted-by: Claude Opus 5
Arch Linux runs on s390x. Installing the repository into a rootfs and
entering it:
bash : 5.3.15(1)-release
uname -m : s390x
glibc : ldd (GNU libc) 2.44
Two things the test taught that sixty-eight successful builds had not.
bash would not start at all: "chroot: No such file or directory" on a
binary that was plainly there. That is the dynamic linker being absent
-- bash asks for /lib/ld64.so.1, and that path exists only through the
usr-merge symlinks the filesystem package installs. Without it an Arch
rootfs starts nothing.
coreutils then failed on libselinux.so.1. Not a port defect: a genuine
dependency that was never built. pacman had in fact listed all of them
before I passed --nodeps -- brotli, libxml2, pam, systemd,
pacman-mirrorlist, libmakepkg-dropins. The resolver works; the
repository was incomplete.
They are added to stage 1 by name, with the reason recorded. A build
that succeeds proves the compiler accepted the source. Only running the
binary proves the package.
--- FR ---
Arch Linux tourne sur s390x. Le depot installe dans un rootfs, puis on
y entre :
bash : 5.3.15(1)-release
uname -m : s390x
glibc : ldd (GNU libc) 2.44
Deux enseignements que soixante-huit compilations reussies n avaient
pas donnes.
bash ne demarrait pas du tout : « chroot: No such file or directory »
sur un binaire pourtant present. C est l interpreteur dynamique qui
manque -- bash reclame /lib/ld64.so.1, chemin qui n existe que par les
liens usr-merge du paquet filesystem. Sans lui, un rootfs Arch ne lance
rien.
coreutils echouait ensuite sur libselinux.so.1. Non pas un defaut du
portage : une dependance reelle jamais batie. pacman les avait
d ailleurs toutes nommees avant que je passe --nodeps -- brotli,
libxml2, pam, systemd, pacman-mirrorlist, libmakepkg-dropins. Le
resolveur fonctionne ; c est le depot qui etait incomplet.
Elles rejoignent l etage 1, avec la raison consignee. Une compilation
reussie prouve que le compilateur a accepte la source. Seul le binaire
qui s execute prouve le paquet.
Assisted-by: Claude Opus 5
install: invalid group: '11'
The filesystem package creates directories with `install -g 11`, and
GNU coreutils rejects a gid that resolves to nothing. gid 11 is `ftp`
on Arch; Ubuntu leaves it free.
This is the circular corner of any bootstrap: the package that DEFINES
/etc/group needs groups that do not exist yet. The way out is to give
the build host the target's id map, not to work around the check --
rewriting the install call to force a numeric gid would produce
directories owned by a group the target does not have.
Only the ids Arch uses and Ubuntu lacks are created, and only when
missing, so a host that is already correct is left alone. Checked one
by one: of 1, 2, 10, 11, 12 and 50, only 11 was absent.
--- FR ---
install: invalid group: '11'
Le paquet filesystem cree des repertoires avec « install -g 11 », et
GNU coreutils refuse un gid qui ne resout vers rien. Le gid 11 est
« ftp » sur Arch ; Ubuntu le laisse libre.
C est le coin circulaire de tout amorcage : le paquet qui DEFINIT
/etc/group reclame des groupes qui n existent pas encore. La sortie est
de donner a l hote de compilation la table d identifiants de la cible,
non de contourner la verification -- forcer l interpretation numerique
produirait des repertoires appartenant a un groupe que la cible n a
pas.
Seuls les identifiants qu Arch utilise et qu Ubuntu n a pas sont crees,
et seulement s ils manquent : un hote deja correct n est pas touche.
Verifie un a un : sur 1, 2, 10, 11, 12 et 50, seul le 11 etait absent.
Assisted-by: Claude Opus 5
Four packages -- grep, gnupg, pacman and curl -- were failing on my own
driver, not on the port. makepkg -f rebuilds but does not wipe $srcdir,
so a re-run re-entered the previous attempt's tree:
patch: ... already exists! Skipping patch.
1 out of 1 hunk ignored
mkdir: build-curl-compat: File exists
makepkg -C now cleans first. Worth stating plainly: those four looked
like port problems for two full rounds, and were not.
gcc: dropping sub-packages from pkgname was not enough. package_gcc()
_picks files out for every front end regardless of what was requested,
and _pick is a mv, so it fails on what was never built:
mv: cannot stat 'usr/bin/gnat': No such file or directory
The _pick lines for the disabled front ends are removed too.
shadow needed libaudit-dev on the host -- one more makedepend that
--nodeps hides until a build stops on it.
--- FR ---
Quatre paquets -- grep, gnupg, pacman et curl -- echouaient a cause de
mon propre pilote, pas du portage. makepkg -f reconstruit mais ne vide
pas $srcdir, si bien qu une reprise revenait dans l arbre de la
tentative precedente :
patch: ... already exists! Skipping patch.
1 out of 1 hunk ignored
mkdir: build-curl-compat: File exists
makepkg -C nettoie desormais d abord. A dire clairement : ces quatre-la
ont eu l air de problemes de portage pendant deux tours entiers, et ne
l etaient pas.
gcc : retirer les sous-paquets de pkgname ne suffisait pas.
package_gcc() extrait des fichiers pour chaque frontal quoi qu on ait
demande, et _pick est un mv, donc il echoue sur ce qui n a jamais ete
bati :
mv: cannot stat 'usr/bin/gnat': No such file or directory
Les lignes _pick des frontaux desactives sont retirees aussi.
shadow reclamait libaudit-dev sur l hote -- un makedepend de plus que
--nodeps masque jusqu a ce qu une compilation s y arrete.
Assisted-by: Claude Opus 5
CHOST was the Debian-style triplet. gcc -dumpmachine reports
s390x-linux-gnu on this host, but config.sub canonicalises that to
s390x-ibm-linux-gnu and GCC builds its tree under the canonical name.
Arch PKGBUILDs assume the canonical form -- theirs is
x86_64-pc-linux-gnu, vendor field present -- so gcc's own PKGBUILD
looked for $CHOST/libstdc++-v3/doc and found nothing:
make: *** s390x-linux-gnu/libstdc++-v3/doc: No such file or directory
while the build had created s390x-ibm-linux-gnu/libstdc++-v3/doc. This
is a port-wide setting, not a gcc quirk: every PKGBUILD that derives a
path from CHOST was pointing one directory sideways.
libassuan fetches from dev.gnupg.org, which is unreachable from this
build host -- measured HTTP 000, while github.com/gpg/libassuan.git and
gnupg.org/ftp both answer. That is a network fact, not a port problem,
so only the transport changes: the pinned tag is untouched and what
gets built is what Arch specifies.
Host dependencies again: doxygen for xz, libunistring for libpsl,
systemd-dev for util-linux. Every one of them was invisible until a
build stopped on it, because --nodeps means pacman never checks
makedepends.
--- FR ---
CHOST portait le triplet de style Debian. Sur cet hote, gcc
-dumpmachine rend s390x-linux-gnu, mais config.sub le canonise en
s390x-ibm-linux-gnu, et GCC batit son arbre sous le nom canonique.
Les PKGBUILD d Arch supposent la forme canonique -- la leur est
x86_64-pc-linux-gnu, champ constructeur present -- si bien que le
PKGBUILD de gcc cherchait $CHOST/libstdc++-v3/doc sans rien trouver :
make: *** s390x-linux-gnu/libstdc++-v3/doc: No such file or directory
alors que la compilation avait cree s390x-ibm-linux-gnu/libstdc++-v3/doc.
C est un reglage de portage, pas une bizarrerie de gcc : tout PKGBUILD
derivant un chemin de CHOST visait un repertoire a cote.
libassuan se telecharge depuis dev.gnupg.org, injoignable depuis cet
hote -- mesure : HTTP 000, quand github.com/gpg/libassuan.git et
gnupg.org/ftp repondent tous deux. C est un fait de reseau, pas un
probleme de portage : seul le transport change, l etiquette epinglee
reste intacte et ce qui se batit est ce qu Arch specifie.
Dependances d hote, encore : doxygen pour xz, libunistring pour libpsl,
systemd-dev pour util-linux. Chacune est restee invisible jusqu a ce
qu une compilation s y arrete, parce que --nodeps interdit a pacman de
verifier les makedepends.
Assisted-by: Claude Opus 5
The same x86 assumption keeps returning in a different disguise: a
32-bit multilib split package. libtool had it, and so do glibc and gcc.
On x86_64 multilib means i686 and Arch wants it; on Z it means the
31-bit ESA/390 ABI that GCC is actively removing:
configure: error: Support for -m31 is deprecated and will be removed.
glibc is the clearest case. The whole compile SUCCEEDS and the glibc
package is written -- then makepkg aborts in package_lib32-glibc() with
"No rule to make target install", because the 32-bit tree was never
configured. The work was done; only the packaging of a tree nobody
built failed.
gcc needed three cuts: front ends written in themselves (Ada, D,
Modula-2, COBOL have no bootstrap compiler here), multilib, and every
lib32 reference including the _pick lines that split out usr/lib32.
arch-meson and arch-cmake are provided as stand-ins. Several PKGBUILDs
call them, they ship in devtools, and devtools is itself an Arch
package -- so during a bootstrap they cannot exist yet and every
PKGBUILD using them stops on "command not found".
A verification lesson, learned twice: grepping a whole PKGBUILD for
"lib32" declares false failures, because the string survives in
comments and in functions that are never called. Only the pkgname array
matters, since that is what makepkg iterates.
--- FR ---
La meme hypothese x86 revient sans cesse sous un autre deguisement : un
paquet scinde multilib 32 bits. libtool l avait, glibc et gcc aussi.
Sur x86_64 le multilib signifie i686 et Arch le veut ; sur Z il designe
l ABI 31 bits ESA/390 que GCC est en train de retirer.
glibc est le cas le plus net. Toute la compilation REUSSIT et le paquet
glibc est ecrit -- puis makepkg abandonne dans package_lib32-glibc()
sur « No rule to make target install », parce que l arbre 32 bits n a
jamais ete configure. Le travail etait fait ; seul l empaquetage d un
arbre que personne n avait bati a echoue.
gcc demandait trois coupes : les frontaux ecrits en eux-memes (Ada, D,
Modula-2 et COBOL n ont ici aucun compilateur d amorcage), le multilib,
et toute reference a lib32 y compris les lignes _pick qui extraient
usr/lib32.
arch-meson et arch-cmake sont fournis en substituts. Plusieurs PKGBUILD
les appellent, ils vivent dans devtools, et devtools est lui-meme un
paquet Arch -- pendant un amorcage ils ne peuvent donc pas exister, et
chaque PKGBUILD qui les utilise s arrete sur « command not found ».
Une lecon de verification, apprise deux fois : chercher « lib32 » dans
tout un PKGBUILD declare de faux echecs, car la chaine survit dans les
commentaires et dans des fonctions jamais appelees. Seul le tableau
pkgname compte, puisque c est lui que makepkg parcourt.
Assisted-by: Claude Opus 5
A run reported "51 built, 0 failed" while glibc, gcc, coreutils and
pacman had all failed. The cause is a bash rule that is easy to forget:
callers invoke build_package inside an "if", and "if" DISABLES set -e
for the whole function body. A failing makepkg fell through to
repo-add, whose success became the function exit status.
build_package now returns explicitly on failure and, more importantly,
verifies that a package file actually exists. An exit code is not
proof; only the artefact is. Measured before the fix: 23 files in the
repository where a hundred were claimed.
First real port patch, applied through a per-package hook rather than
by hand: the glibc PKGBUILD passes --enable-sframe, and s390x has no
SFrame at all -- configure refuses outright. Hooks re-clone cleanly, so
an upstream change is never silently discarded.
--nocheck for stage 1: these test suites run against the HOST
libraries, not the Arch ones, so their verdict says nothing about the
port. acl failed its check step on a sound build. Stage 2 runs them for
real.
The remaining failures were host makedepends that --nodeps hides: po4a,
gnat, debuginfod and jansson are now installed up front.
--- FR ---
Une execution annoncait « 51 built, 0 failed » alors que glibc, gcc,
coreutils et pacman avaient tous echoue. La cause est une regle de bash
qu on oublie : build_package est appelee dans un « if », et « if »
DESACTIVE set -e pour tout le corps de la fonction. Un makepkg en echec
poursuivait jusqu a repo-add, dont la reussite devenait le code de
sortie.
build_package rend desormais la main explicitement en cas d echec et,
surtout, verifie qu un fichier de paquet existe vraiment. Un code de
sortie ne prouve rien ; seul l artefact prouve. Mesure avant
correction : 23 fichiers dans le depot la ou cent etaient annonces.
Premier vrai correctif de portage, applique par crochet et non a la
main : le PKGBUILD de glibc passe --enable-sframe, et s390x n a aucun
SFrame -- configure refuse net. Les crochets survivent a un reclonage,
donc une evolution amont n est jamais perdue en silence.
--nocheck pour l etage 1 : ces suites s executent contre les
bibliotheques de l HOTE, pas celles d Arch, et leur verdict ne dit rien
du portage. acl echouait a son etape check sur une compilation saine.
L etage 2 les executera pour de vrai.
Les autres echecs etaient des makedepends d hote que --nodeps masque :
po4a, gnat, debuginfod et jansson sont poses d entree.
Assisted-by: Claude Opus 5
Forty-odd packages in link-time order, from linux-api-headers to
pacman itself. The order follows what a compiler actually needs, not
pacman metadata: --nodeps means nothing is ever checked, so anything
required at link time has to exist already.
A failure does not stop the run. One missing package must not hide the
state of the forty that follow, so failures are collected and reported
at the end, each with its own log. A state file makes the run
resumable, which matters when a single gcc build is measured in tens
of minutes.
The header states why stage 1 is not the port: everything here links
against the host glibc, because Arch glibc needs an Arch gcc which
needs an Arch glibc. Stages 2 and 3 break that circle.
bootstrap-pacman.sh now guards its own main so it can be sourced for
build_package without re-running the whole bootstrap.
--- FR ---
Une quarantaine de paquets dans l ordre des dependances de lien, de
linux-api-headers a pacman lui-meme. L ordre suit ce dont un
compilateur a reellement besoin, pas les metadonnees de pacman :
--nodeps ne verifie jamais rien, donc tout ce qui sert au lien doit
deja exister.
Un echec n arrete pas la course. Un paquet manquant ne doit pas
masquer l etat des quarante suivants : les echecs sont collectes et
rapportes a la fin, chacun avec son journal. Un fichier d etat rend la
reprise possible, ce qui compte quand un seul gcc se compte en
dizaines de minutes.
L en-tete dit pourquoi l etage 1 n est pas le portage : tout s y lie a
la glibc de l hote, parce que la glibc d Arch reclame un gcc d Arch
qui reclame une glibc d Arch. Les etages 2 et 3 brisent ce cercle.
bootstrap-pacman.sh garde desormais son main pour etre sourcable et
fournir build_package sans relancer tout l amorcage.
Assisted-by: Claude Opus 5
The README lists pacman, bash and coreutils as three missing pieces.
They are not three tasks: pacman is the only one that matters, because
its source tree also ships makepkg and repo-add. Once those run, every
remaining package stops being hand-work and becomes makepkg on the
upstream PKGBUILD.
pacman 7.1.0 builds unpatched on s390x. No cross-compilation is
involved: on native hardware the whole userspace builds at full speed,
which removes the z/VM round-trip the other scripts need.
Measured end to end: zlib built from the official PKGBUILD yields
zlib, zlib-static and minizip, all tagged arch = s390x, the library
reporting "ELF 64-bit MSB shared object, IBM S/390", and repo-add
indexing them into a usable core.db.
--- FR ---
Le README annonce pacman, bash et coreutils comme trois pieces
manquantes. Ce ne sont pas trois travaux : seul pacman compte, parce
que son arbre source livre aussi makepkg et repo-add. Des qu ils
tournent, chaque paquet restant cesse d etre du travail manuel et
devient un makepkg sur le PKGBUILD amont.
pacman 7.1.0 se compile sans correctif sur s390x. Aucune compilation
croisee n intervient : sur du materiel natif tout l espace utilisateur
se batit a pleine vitesse, ce qui supprime l aller-retour z/VM dont
dependent les autres scripts.
Mesure de bout en bout : zlib bati depuis le PKGBUILD officiel produit
zlib, zlib-static et minizip, tous marques arch = s390x, la
bibliotheque se declarant « ELF 64-bit MSB shared object, IBM S/390 »,
et repo-add les indexant dans un core.db utilisable.
Assisted-by: Claude Opus 5
