[ADD] port patches: gcc front ends, binutils gold, libtool multilib
Three more upstream PKGBUILDs assume x86_64, each in a different way,
and each is dropped rather than repaired because the thing being
dropped is architecture-specific by nature.
gcc: Ada and D are written in themselves and need an existing compiler
of the same language. Ubuntu ships gnat, but not one GCC 15 accepts,
and there is no D bootstrap compiler here at all. Modula-2 and COBOL
have the same shape. Front ends reduced to c, c++, fortran, lto, objc
and obj-c++, which is everything this port and ERPLibre compile.
binutils: gold is x86-centric, deprecated upstream since 2.44, and
built by no distribution that ships s390x. ld.bfd is the linker on Z.
binutils builds once gold is disabled -- measured.
libtool: the lib32-libltdl split package is i686-on-x86_64 multilib.
Its build step is already guarded by CARCH, but prepare() copies the
tree to src/libtool32 unconditionally and the package function then
packages a tree nobody built.
Two host-layout bridges were also needed. Ubuntu multiarch puts asm/,
bits/, gnu/ and sys/sdt.h under /usr/include/s390x-linux-gnu, while
glibc builds with -nostdinc and expects the classic layout:
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Symlinks make the host look like Arch for those paths. sys/ needed the
files linked, not the directory, since /usr/include/sys already exists.
--- FR ---
Trois PKGBUILD amont de plus supposent x86_64, chacun a sa maniere, et
chacun est retire plutot que repare : ce qu on retire est par nature
propre a une architecture.
gcc : Ada et D sont ecrits en eux-memes et reclament un compilateur
existant du meme langage. Ubuntu livre gnat, mais pas une version que
GCC 15 accepte, et il n y a ici aucun compilateur D d amorcage.
Modula-2 et COBOL posent le meme probleme. Les frontaux se reduisent a
c, c++, fortran, lto, objc et obj-c++, ce qui couvre tout ce que ce
portage et ERPLibre compilent.
binutils : gold est centre sur x86, abandonne en amont depuis 2.44, et
construit par aucune distribution livrant s390x. Sur Z, l editeur de
liens est ld.bfd. binutils se construit des que gold est desactive --
mesure.
libtool : le paquet scinde lib32-libltdl est du multilib i686 sur
x86_64. Son etape de compilation est deja gardee par CARCH, mais
prepare() copie l arbre vers src/libtool32 sans condition, et la
fonction de paquet empaquette ensuite un arbre que personne n a bati.
Deux ponts de disposition d hote etaient aussi necessaires. Le
multiarch d Ubuntu place asm/, bits/, gnu/ et sys/sdt.h sous
/usr/include/s390x-linux-gnu, quand glibc compile avec -nostdinc et
attend la disposition classique :
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Des liens symboliques donnent a l hote l allure d Arch pour ces
chemins. Pour sys/ il faut lier les fichiers et non le repertoire,
puisque /usr/include/sys existe deja.
Assisted-by: Claude Opus 5
2026-08-15 21:01:18 -04:00
|
|
|
#!/usr/bin/env bash
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
# gcc: three x86 assumptions, all fatal on s390x.
|
[ADD] port patches: gcc front ends, binutils gold, libtool multilib
Three more upstream PKGBUILDs assume x86_64, each in a different way,
and each is dropped rather than repaired because the thing being
dropped is architecture-specific by nature.
gcc: Ada and D are written in themselves and need an existing compiler
of the same language. Ubuntu ships gnat, but not one GCC 15 accepts,
and there is no D bootstrap compiler here at all. Modula-2 and COBOL
have the same shape. Front ends reduced to c, c++, fortran, lto, objc
and obj-c++, which is everything this port and ERPLibre compile.
binutils: gold is x86-centric, deprecated upstream since 2.44, and
built by no distribution that ships s390x. ld.bfd is the linker on Z.
binutils builds once gold is disabled -- measured.
libtool: the lib32-libltdl split package is i686-on-x86_64 multilib.
Its build step is already guarded by CARCH, but prepare() copies the
tree to src/libtool32 unconditionally and the package function then
packages a tree nobody built.
Two host-layout bridges were also needed. Ubuntu multiarch puts asm/,
bits/, gnu/ and sys/sdt.h under /usr/include/s390x-linux-gnu, while
glibc builds with -nostdinc and expects the classic layout:
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Symlinks make the host look like Arch for those paths. sys/ needed the
files linked, not the directory, since /usr/include/sys already exists.
--- FR ---
Trois PKGBUILD amont de plus supposent x86_64, chacun a sa maniere, et
chacun est retire plutot que repare : ce qu on retire est par nature
propre a une architecture.
gcc : Ada et D sont ecrits en eux-memes et reclament un compilateur
existant du meme langage. Ubuntu livre gnat, mais pas une version que
GCC 15 accepte, et il n y a ici aucun compilateur D d amorcage.
Modula-2 et COBOL posent le meme probleme. Les frontaux se reduisent a
c, c++, fortran, lto, objc et obj-c++, ce qui couvre tout ce que ce
portage et ERPLibre compilent.
binutils : gold est centre sur x86, abandonne en amont depuis 2.44, et
construit par aucune distribution livrant s390x. Sur Z, l editeur de
liens est ld.bfd. binutils se construit des que gold est desactive --
mesure.
libtool : le paquet scinde lib32-libltdl est du multilib i686 sur
x86_64. Son etape de compilation est deja gardee par CARCH, mais
prepare() copie l arbre vers src/libtool32 sans condition, et la
fonction de paquet empaquette ensuite un arbre que personne n a bati.
Deux ponts de disposition d hote etaient aussi necessaires. Le
multiarch d Ubuntu place asm/, bits/, gnu/ et sys/sdt.h sous
/usr/include/s390x-linux-gnu, quand glibc compile avec -nostdinc et
attend la disposition classique :
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Des liens symboliques donnent a l hote l allure d Arch pour ces
chemins. Pour sys/ il faut lier les fichiers et non le repertoire,
puisque /usr/include/sys existe deja.
Assisted-by: Claude Opus 5
2026-08-15 21:01:18 -04:00
|
|
|
#
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
# 1. Front ends written in themselves.
|
[ADD] port patches: gcc front ends, binutils gold, libtool multilib
Three more upstream PKGBUILDs assume x86_64, each in a different way,
and each is dropped rather than repaired because the thing being
dropped is architecture-specific by nature.
gcc: Ada and D are written in themselves and need an existing compiler
of the same language. Ubuntu ships gnat, but not one GCC 15 accepts,
and there is no D bootstrap compiler here at all. Modula-2 and COBOL
have the same shape. Front ends reduced to c, c++, fortran, lto, objc
and obj-c++, which is everything this port and ERPLibre compile.
binutils: gold is x86-centric, deprecated upstream since 2.44, and
built by no distribution that ships s390x. ld.bfd is the linker on Z.
binutils builds once gold is disabled -- measured.
libtool: the lib32-libltdl split package is i686-on-x86_64 multilib.
Its build step is already guarded by CARCH, but prepare() copies the
tree to src/libtool32 unconditionally and the package function then
packages a tree nobody built.
Two host-layout bridges were also needed. Ubuntu multiarch puts asm/,
bits/, gnu/ and sys/sdt.h under /usr/include/s390x-linux-gnu, while
glibc builds with -nostdinc and expects the classic layout:
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Symlinks make the host look like Arch for those paths. sys/ needed the
files linked, not the directory, since /usr/include/sys already exists.
--- FR ---
Trois PKGBUILD amont de plus supposent x86_64, chacun a sa maniere, et
chacun est retire plutot que repare : ce qu on retire est par nature
propre a une architecture.
gcc : Ada et D sont ecrits en eux-memes et reclament un compilateur
existant du meme langage. Ubuntu livre gnat, mais pas une version que
GCC 15 accepte, et il n y a ici aucun compilateur D d amorcage.
Modula-2 et COBOL posent le meme probleme. Les frontaux se reduisent a
c, c++, fortran, lto, objc et obj-c++, ce qui couvre tout ce que ce
portage et ERPLibre compilent.
binutils : gold est centre sur x86, abandonne en amont depuis 2.44, et
construit par aucune distribution livrant s390x. Sur Z, l editeur de
liens est ld.bfd. binutils se construit des que gold est desactive --
mesure.
libtool : le paquet scinde lib32-libltdl est du multilib i686 sur
x86_64. Son etape de compilation est deja gardee par CARCH, mais
prepare() copie l arbre vers src/libtool32 sans condition, et la
fonction de paquet empaquette ensuite un arbre que personne n a bati.
Deux ponts de disposition d hote etaient aussi necessaires. Le
multiarch d Ubuntu place asm/, bits/, gnu/ et sys/sdt.h sous
/usr/include/s390x-linux-gnu, quand glibc compile avec -nostdinc et
attend la disposition classique :
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Des liens symboliques donnent a l hote l allure d Arch pour ces
chemins. Pour sys/ il faut lier les fichiers et non le repertoire,
puisque /usr/include/sys existe deja.
Assisted-by: Claude Opus 5
2026-08-15 21:01:18 -04:00
|
|
|
#
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
# configure: error: GNAT is required to build ada
|
|
|
|
|
# configure: error: GDC is required to build d
|
[ADD] port patches: gcc front ends, binutils gold, libtool multilib
Three more upstream PKGBUILDs assume x86_64, each in a different way,
and each is dropped rather than repaired because the thing being
dropped is architecture-specific by nature.
gcc: Ada and D are written in themselves and need an existing compiler
of the same language. Ubuntu ships gnat, but not one GCC 15 accepts,
and there is no D bootstrap compiler here at all. Modula-2 and COBOL
have the same shape. Front ends reduced to c, c++, fortran, lto, objc
and obj-c++, which is everything this port and ERPLibre compile.
binutils: gold is x86-centric, deprecated upstream since 2.44, and
built by no distribution that ships s390x. ld.bfd is the linker on Z.
binutils builds once gold is disabled -- measured.
libtool: the lib32-libltdl split package is i686-on-x86_64 multilib.
Its build step is already guarded by CARCH, but prepare() copies the
tree to src/libtool32 unconditionally and the package function then
packages a tree nobody built.
Two host-layout bridges were also needed. Ubuntu multiarch puts asm/,
bits/, gnu/ and sys/sdt.h under /usr/include/s390x-linux-gnu, while
glibc builds with -nostdinc and expects the classic layout:
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Symlinks make the host look like Arch for those paths. sys/ needed the
files linked, not the directory, since /usr/include/sys already exists.
--- FR ---
Trois PKGBUILD amont de plus supposent x86_64, chacun a sa maniere, et
chacun est retire plutot que repare : ce qu on retire est par nature
propre a une architecture.
gcc : Ada et D sont ecrits en eux-memes et reclament un compilateur
existant du meme langage. Ubuntu livre gnat, mais pas une version que
GCC 15 accepte, et il n y a ici aucun compilateur D d amorcage.
Modula-2 et COBOL posent le meme probleme. Les frontaux se reduisent a
c, c++, fortran, lto, objc et obj-c++, ce qui couvre tout ce que ce
portage et ERPLibre compilent.
binutils : gold est centre sur x86, abandonne en amont depuis 2.44, et
construit par aucune distribution livrant s390x. Sur Z, l editeur de
liens est ld.bfd. binutils se construit des que gold est desactive --
mesure.
libtool : le paquet scinde lib32-libltdl est du multilib i686 sur
x86_64. Son etape de compilation est deja gardee par CARCH, mais
prepare() copie l arbre vers src/libtool32 sans condition, et la
fonction de paquet empaquette ensuite un arbre que personne n a bati.
Deux ponts de disposition d hote etaient aussi necessaires. Le
multiarch d Ubuntu place asm/, bits/, gnu/ et sys/sdt.h sous
/usr/include/s390x-linux-gnu, quand glibc compile avec -nostdinc et
attend la disposition classique :
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Des liens symboliques donnent a l hote l allure d Arch pour ces
chemins. Pour sys/ il faut lier les fichiers et non le repertoire,
puisque /usr/include/sys existe deja.
Assisted-by: Claude Opus 5
2026-08-15 21:01:18 -04:00
|
|
|
#
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
# Ada and D need an existing compiler of the same language; Modula-2 and
|
|
|
|
|
# COBOL have the same shape. Nothing in a core bootstrap, and nothing in
|
|
|
|
|
# ERPLibre, is written in any of them.
|
[ADD] port patches: gcc front ends, binutils gold, libtool multilib
Three more upstream PKGBUILDs assume x86_64, each in a different way,
and each is dropped rather than repaired because the thing being
dropped is architecture-specific by nature.
gcc: Ada and D are written in themselves and need an existing compiler
of the same language. Ubuntu ships gnat, but not one GCC 15 accepts,
and there is no D bootstrap compiler here at all. Modula-2 and COBOL
have the same shape. Front ends reduced to c, c++, fortran, lto, objc
and obj-c++, which is everything this port and ERPLibre compile.
binutils: gold is x86-centric, deprecated upstream since 2.44, and
built by no distribution that ships s390x. ld.bfd is the linker on Z.
binutils builds once gold is disabled -- measured.
libtool: the lib32-libltdl split package is i686-on-x86_64 multilib.
Its build step is already guarded by CARCH, but prepare() copies the
tree to src/libtool32 unconditionally and the package function then
packages a tree nobody built.
Two host-layout bridges were also needed. Ubuntu multiarch puts asm/,
bits/, gnu/ and sys/sdt.h under /usr/include/s390x-linux-gnu, while
glibc builds with -nostdinc and expects the classic layout:
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Symlinks make the host look like Arch for those paths. sys/ needed the
files linked, not the directory, since /usr/include/sys already exists.
--- FR ---
Trois PKGBUILD amont de plus supposent x86_64, chacun a sa maniere, et
chacun est retire plutot que repare : ce qu on retire est par nature
propre a une architecture.
gcc : Ada et D sont ecrits en eux-memes et reclament un compilateur
existant du meme langage. Ubuntu livre gnat, mais pas une version que
GCC 15 accepte, et il n y a ici aucun compilateur D d amorcage.
Modula-2 et COBOL posent le meme probleme. Les frontaux se reduisent a
c, c++, fortran, lto, objc et obj-c++, ce qui couvre tout ce que ce
portage et ERPLibre compilent.
binutils : gold est centre sur x86, abandonne en amont depuis 2.44, et
construit par aucune distribution livrant s390x. Sur Z, l editeur de
liens est ld.bfd. binutils se construit des que gold est desactive --
mesure.
libtool : le paquet scinde lib32-libltdl est du multilib i686 sur
x86_64. Son etape de compilation est deja gardee par CARCH, mais
prepare() copie l arbre vers src/libtool32 sans condition, et la
fonction de paquet empaquette ensuite un arbre que personne n a bati.
Deux ponts de disposition d hote etaient aussi necessaires. Le
multiarch d Ubuntu place asm/, bits/, gnu/ et sys/sdt.h sous
/usr/include/s390x-linux-gnu, quand glibc compile avec -nostdinc et
attend la disposition classique :
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Des liens symboliques donnent a l hote l allure d Arch pour ces
chemins. Pour sys/ il faut lier les fichiers et non le repertoire,
puisque /usr/include/sys existe deja.
Assisted-by: Claude Opus 5
2026-08-15 21:01:18 -04:00
|
|
|
#
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
# 2. Multilib, which on Z means the 31-bit ABI:
|
|
|
|
|
#
|
|
|
|
|
# configure: error: Support for -m31 is deprecated and will be removed.
|
|
|
|
|
# Specify --enable-obsolete to build it anyway.
|
|
|
|
|
#
|
|
|
|
|
# On x86_64 multilib means i686 and Arch wants it. Here it means the
|
|
|
|
|
# 31-bit ESA/390 ABI that GCC is actively removing. Disabled rather than
|
|
|
|
|
# resurrected as obsolete.
|
|
|
|
|
#
|
|
|
|
|
# 3. The lib32 split package and every _pick that feeds it.
|
|
|
|
|
#
|
|
|
|
|
# The front-end reduction is a STAGE 1 CONCESSION: once the port is
|
|
|
|
|
# self-hosting, its own gcc can bootstrap Ada and D. The multilib and lib32
|
|
|
|
|
# removals are permanent -- they are architectural.
|
[ADD] port patches: gcc front ends, binutils gold, libtool multilib
Three more upstream PKGBUILDs assume x86_64, each in a different way,
and each is dropped rather than repaired because the thing being
dropped is architecture-specific by nature.
gcc: Ada and D are written in themselves and need an existing compiler
of the same language. Ubuntu ships gnat, but not one GCC 15 accepts,
and there is no D bootstrap compiler here at all. Modula-2 and COBOL
have the same shape. Front ends reduced to c, c++, fortran, lto, objc
and obj-c++, which is everything this port and ERPLibre compile.
binutils: gold is x86-centric, deprecated upstream since 2.44, and
built by no distribution that ships s390x. ld.bfd is the linker on Z.
binutils builds once gold is disabled -- measured.
libtool: the lib32-libltdl split package is i686-on-x86_64 multilib.
Its build step is already guarded by CARCH, but prepare() copies the
tree to src/libtool32 unconditionally and the package function then
packages a tree nobody built.
Two host-layout bridges were also needed. Ubuntu multiarch puts asm/,
bits/, gnu/ and sys/sdt.h under /usr/include/s390x-linux-gnu, while
glibc builds with -nostdinc and expects the classic layout:
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Symlinks make the host look like Arch for those paths. sys/ needed the
files linked, not the directory, since /usr/include/sys already exists.
--- FR ---
Trois PKGBUILD amont de plus supposent x86_64, chacun a sa maniere, et
chacun est retire plutot que repare : ce qu on retire est par nature
propre a une architecture.
gcc : Ada et D sont ecrits en eux-memes et reclament un compilateur
existant du meme langage. Ubuntu livre gnat, mais pas une version que
GCC 15 accepte, et il n y a ici aucun compilateur D d amorcage.
Modula-2 et COBOL posent le meme probleme. Les frontaux se reduisent a
c, c++, fortran, lto, objc et obj-c++, ce qui couvre tout ce que ce
portage et ERPLibre compilent.
binutils : gold est centre sur x86, abandonne en amont depuis 2.44, et
construit par aucune distribution livrant s390x. Sur Z, l editeur de
liens est ld.bfd. binutils se construit des que gold est desactive --
mesure.
libtool : le paquet scinde lib32-libltdl est du multilib i686 sur
x86_64. Son etape de compilation est deja gardee par CARCH, mais
prepare() copie l arbre vers src/libtool32 sans condition, et la
fonction de paquet empaquette ensuite un arbre que personne n a bati.
Deux ponts de disposition d hote etaient aussi necessaires. Le
multiarch d Ubuntu place asm/, bits/, gnu/ et sys/sdt.h sous
/usr/include/s390x-linux-gnu, quand glibc compile avec -nostdinc et
attend la disposition classique :
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Des liens symboliques donnent a l hote l allure d Arch pour ces
chemins. Pour sys/ il faut lier les fichiers et non le repertoire,
puisque /usr/include/sys existe deja.
Assisted-by: Claude Opus 5
2026-08-15 21:01:18 -04:00
|
|
|
set -euo pipefail
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
|
[FIX] gcc: do not rewrite the libgccjit language list
The PKGBUILD configures gcc twice: once for the compiler, once for
libgccjit with --enable-languages=jit. The hook rewrote every
occurrence, so the second tree built a compiler instead of a library
and package() died on
cp: cannot stat 'gcc/libgccjit.so*': No such file or directory
after forty minutes of compiling -- the worst kind of failure, at the
very end, from a patch that looked right.
The sed now skips any line containing jit. A patch that rewrites "every
occurrence" of anything in a PKGBUILD should be suspected by default:
these files configure the same source tree several times, for different
outputs.
--- FR ---
Le PKGBUILD configure gcc deux fois : une fois pour le compilateur, une
fois pour libgccjit avec --enable-languages=jit. Le crochet reecrivait
toutes les occurrences, si bien que le second arbre batissait un
compilateur au lieu d une bibliotheque, et package() mourait sur
cp: cannot stat 'gcc/libgccjit.so*': No such file or directory
apres quarante minutes de compilation -- le pire genre d echec, tout a
la fin, venu d un correctif qui semblait juste.
Le sed ecarte desormais toute ligne contenant jit. Un correctif qui
reecrit « toutes les occurrences » de quoi que ce soit dans un PKGBUILD
doit etre suspecte d office : ces fichiers configurent plusieurs fois le
meme arbre source, pour des sorties differentes.
Assisted-by: Claude Opus 5
2026-08-16 01:18:45 -04:00
|
|
|
# Only the MAIN build. The PKGBUILD configures gcc twice: once for the
|
|
|
|
|
# compiler, once for libgccjit with --enable-languages=jit. Rewriting
|
|
|
|
|
# every occurrence clobbered the second one, so the jit tree built a
|
|
|
|
|
# compiler instead of a library and package() died on
|
|
|
|
|
# cp: cannot stat 'gcc/libgccjit.so*': No such file or directory
|
|
|
|
|
# after forty minutes of compiling. Match the language list, never 'jit'.
|
|
|
|
|
sed -i '/--enable-languages=jit/!s/^\(\s*--enable-languages=\).*\\$/\1c,c++,fortran,lto,objc,obj-c++ \\/' PKGBUILD
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
if grep -qE 'enable-languages=[^ ]*(ada|,d,|m2|cobol)' PKGBUILD; then
|
|
|
|
|
echo "gcc: a self-hosted front end is still enabled" >&2; exit 1
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
if grep -q -- '--enable-multilib' PKGBUILD; then
|
|
|
|
|
sed -i 's/--enable-multilib/--disable-multilib/' PKGBUILD
|
|
|
|
|
else
|
|
|
|
|
sed -i 's/^\(\s*\)--enable-languages=\(.*\)$/\1--disable-multilib \\\n\1--enable-languages=\2/' PKGBUILD
|
|
|
|
|
fi
|
|
|
|
|
grep -q -- '--disable-multilib' PKGBUILD || { echo "gcc: multilib not disabled" >&2; exit 1; }
|
|
|
|
|
|
|
|
|
|
# The pkgname array lists one sub-package per front end. makepkg calls
|
|
|
|
|
# package_<name>() for every entry, so those whose language is now off would
|
|
|
|
|
# package an empty tree. Names absent from the array are never called, so
|
|
|
|
|
# pruning it is enough -- the functions themselves can stay.
|
|
|
|
|
python3 - <<'PY'
|
|
|
|
|
import io, re
|
|
|
|
|
drop = {
|
|
|
|
|
"gcc-ada", "gcc-d", "gcc-gcobol", "gcc-go", "gcc-m2", "gcc-rust",
|
|
|
|
|
"libgm2", "libgo", "libgphobos", "libgcobol",
|
|
|
|
|
"lib32-gcc-libs",
|
[FIX] gcc: libquadmath does not exist on s390x; python alias for util-linux
mv: cannot stat 'usr/lib/libquadmath.a': No such file or directory
libquadmath implements __float128, which exists on x86 and ia64. On
s390x the directory is CONFIGURED -- it holds a Makefile, a config.log
and a config.status -- but no library is ever built. The half-created
directory is what makes this one confusing: it looks like a build that
failed rather than a target that has nothing to build.
Dropped from pkgname, from the _pick lines, and from the depends entry
in another sub-package. That last one matters: with --nodeps it is
harmless at build time and fatal at install time, which is exactly the
kind of defect that surfaces long after the build that introduced it.
package_libquadmath() is left in place. makepkg never calls a function
whose name is absent from pkgname, so removing it would be churn.
util-linux calls "python", which Ubuntu does not provide -- only
python3. python-is-python3 supplies the name.
--- FR ---
mv: cannot stat 'usr/lib/libquadmath.a': No such file or directory
libquadmath implemente __float128, qui existe sur x86 et ia64. Sur
s390x le repertoire est CONFIGURE -- il contient un Makefile, un
config.log et un config.status -- mais aucune bibliotheque n y est
jamais batie. C est ce repertoire a moitie cree qui rend le cas
trompeur : il a l air d une compilation ratee plutot que d une cible
qui n a rien a construire.
Retire de pkgname, des lignes _pick, et de la declaration depends d un
autre sous-paquet. Ce dernier point compte : avec --nodeps il est
inoffensif a la compilation et fatal a l installation, exactement le
genre de defaut qui se revele longtemps apres la compilation qui l a
introduit.
package_libquadmath() reste en place. makepkg n appelle jamais une
fonction dont le nom est absent de pkgname ; la retirer serait du
bruit.
util-linux appelle « python », qu Ubuntu ne fournit pas -- seulement
python3. python-is-python3 fournit le nom.
Assisted-by: Claude Opus 5
2026-08-16 19:52:55 -04:00
|
|
|
# __float128 est propre a x86 et ia64. s390x configure libquadmath
|
|
|
|
|
# -- le repertoire ne contient qu un Makefile et un config.log -- mais
|
|
|
|
|
# ne batit aucune bibliotheque, d ou l arret sur
|
|
|
|
|
# mv: cannot stat 'usr/lib/libquadmath.a'
|
|
|
|
|
"libquadmath",
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
# Hardware-assisted ASan exists on x86_64 and aarch64 only.
|
|
|
|
|
"libhwasan",
|
|
|
|
|
}
|
|
|
|
|
s = io.open("PKGBUILD", encoding="utf-8").read()
|
|
|
|
|
m = re.search(r"^pkgname=\(\n(.*?)^\)$", s, re.S | re.M)
|
|
|
|
|
assert m, "pkgname array not found"
|
|
|
|
|
kept = [ln for ln in m.group(1).splitlines() if ln.strip() not in drop]
|
|
|
|
|
s = s[:m.start(1)] + "\n".join(kept) + "\n" + s[m.end(1):]
|
|
|
|
|
s = re.sub(r"\npackage_lib32-gcc-libs\(\)\s*\{.*?\n\}\n", "\n", s, flags=re.S)
|
|
|
|
|
io.open("PKGBUILD", "w", encoding="utf-8").write(s)
|
|
|
|
|
print("gcc: sub-packages kept -> %d" % len(kept))
|
|
|
|
|
PY
|
|
|
|
|
|
|
|
|
|
# Two lingering references outside the array: a makedepends entry on a
|
|
|
|
|
# package that does not exist for this architecture, and a run of
|
|
|
|
|
# `_pick lib32-gcc-libs usr/lib32/...` splitting out files multilib would
|
|
|
|
|
# have produced. With multilib off, usr/lib32 is empty.
|
|
|
|
|
sed -i '/^\s*lib32-gcc-libs\s*$/d' PKGBUILD
|
|
|
|
|
sed -i '/_pick lib32-gcc-libs/d' PKGBUILD
|
|
|
|
|
sed -i '/lib32-gcc-libs: for generating code/d' PKGBUILD
|
|
|
|
|
|
[ADD] gcc: make libgccjit optional, strip the remaining lib32 work
Arch configures and compiles the whole gcc tree a SECOND time just for
libgccjit, because it needs --enable-host-shared and applying that to
the main compiler would slow it down. That pass is about half of gcc's
build time -- twenty minutes per attempt on this hardware -- and
nothing in the bootstrap or in ERPLibre uses it.
It is now skipped by default and restored with:
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verified both ways: off leaves zero libgccjit references in the
PKGBUILD, on leaves the ten upstream ones untouched, including the
--enable-languages=jit line the main-build sed deliberately avoids.
package_gcc() still manipulated the 32-bit tree in several places, and
each fails once multilib is off because usr/lib32 never exists:
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
The link named in that error is the one that SUCCEEDED; the failure is
the usr/lib32 line right after it in the same loop. Read alone, it
sends you hunting for a missing libatomic that is in fact present. The
same loop also linked the D runtimes, gone with the D front end.
--- FR ---
Arch configure et compile l arbre gcc entier une SECONDE fois pour le
seul libgccjit, qui reclame --enable-host-shared -- appliquer cette
option au compilateur principal le ralentirait. Cette passe represente
environ la moitie du temps de compilation de gcc, soit vingt minutes
par tentative sur cette machine, et rien dans l amorcage ni dans
ERPLibre ne s en sert.
Elle est desormais ecartee par defaut et se retablit par :
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verifie dans les deux sens : desactive, il ne reste aucune reference a
libgccjit dans le PKGBUILD ; active, les dix references amont restent
intactes, y compris la ligne --enable-languages=jit que le sed du
build principal evite deliberement.
package_gcc() manipulait encore l arbre 32 bits en plusieurs endroits,
et chacun echoue une fois le multilib retire, puisque usr/lib32
n existe jamais :
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
Le lien nomme dans cette erreur est celui qui a REUSSI ; l echec est la
ligne usr/lib32 juste apres, dans la meme boucle. Lue seule, elle fait
chercher un libatomic manquant qui est pourtant bien la. La meme boucle
liait aussi les runtimes D, partis avec le frontal D.
Assisted-by: Claude Opus 5
2026-08-16 01:54:13 -04:00
|
|
|
# package_gcc() still manipulates the 32-bit tree in several places, and
|
|
|
|
|
# every one of them fails once multilib is off, because usr/lib32 never
|
|
|
|
|
# exists:
|
|
|
|
|
#
|
|
|
|
|
# 'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
|
|
|
|
|
# ln: No such file or directory
|
|
|
|
|
#
|
|
|
|
|
# The link that is reported is the one that SUCCEEDED; the failure is the
|
|
|
|
|
# usr/lib32 line right after it, in the same loop. Reading the error alone
|
|
|
|
|
# sends you hunting for a missing libatomic that is in fact present.
|
|
|
|
|
sed -i '/usr\/lib32/d; /_libdir\/32/d' PKGBUILD
|
[FIX] gcc: 32-bit paths hidden in brace expansions; more host libraries
Two more shapes of the same multilib assumption, and the second is a
trap worth naming.
Some _pick lines write the 32-bit path in full:
mv: cannot stat 'usr/lib/gcc/s390x-ibm-linux-gnu/16/32/finclude/'
Others write BOTH paths in one line with a brace expansion --
$_libdir/{,32/}finclude/ expands to the normal path and the 32-bit one.
Deleting such a line would silently lose the path that DOES exist, so
only the alternative is removed: {,32/} and {,32} become nothing.
That distinction matters. A blanket "delete every line mentioning 32"
would have dropped gcc-fortran's finclude, libcaf and libgfortran.spec
from the package, and the loss would only have surfaced later, in
something that failed to link.
Host libraries again: libcryptsetup for util-linux, libgcrypt, libksba
and npth for gnupg, libpam for shadow.
--- FR ---
Deux formes de plus de la meme hypothese multilib, et la seconde est un
piege qui merite d etre nomme.
Certaines lignes _pick ecrivent le chemin 32 bits en entier :
mv: cannot stat 'usr/lib/gcc/s390x-ibm-linux-gnu/16/32/finclude/'
D autres ecrivent les DEUX chemins d un coup par expansion d accolades
-- $_libdir/{,32/}finclude/ produit le chemin normal et celui en 32
bits. Supprimer une telle ligne perdrait en silence le chemin qui
EXISTE, donc seule l alternative disparait : {,32/} et {,32} deviennent
rien.
La distinction compte. Un « supprimer toute ligne mentionnant 32 »
aurait retire finclude, libcaf et libgfortran.spec du paquet
gcc-fortran, et la perte ne serait apparue que plus tard, dans quelque
chose qui refuse de se lier.
Bibliotheques d hote, encore : libcryptsetup pour util-linux, libgcrypt,
libksba et npth pour gnupg, libpam pour shadow.
Assisted-by: Claude Opus 5
2026-08-16 05:19:20 -04:00
|
|
|
# Some 32-bit paths are written out in full rather than through
|
|
|
|
|
# $_libdir/32, so the pattern above misses them:
|
|
|
|
|
# mv: cannot stat 'usr/lib/gcc/s390x-ibm-linux-gnu/16/32/finclude/'
|
|
|
|
|
sed -i '/_pick .*\/32\//d' PKGBUILD
|
|
|
|
|
# Others write BOTH paths with a brace expansion -- $_libdir/{,32/}finclude/
|
|
|
|
|
# expands to the normal and the 32-bit path in one go. Deleting the line
|
|
|
|
|
# would lose the normal path too, so only the 32-bit alternative goes.
|
|
|
|
|
sed -i 's|{,32/}||g; s|{,32}||g' PKGBUILD
|
[FIX] gcc: s390x installs to lib64, Arch expects lib
package_gcc() reached its very last step and stopped on one file:
mv: cannot stat 'usr/lib/libgfortran.spec': No such file or directory
The file exists, in usr/lib64/libgfortran.spec. lib64 is GCC's default
MULTILIB_OSDIRNAMES for 64-bit Z, while Arch puts everything in
usr/lib. So this is not one stray path: the whole package layout
differs, and every _pick naming usr/lib would miss the same way.
The trees are merged before any _pick runs, which leaves the upstream
package definitions working unchanged rather than rewriting each path
one at a time -- and keeps working if Arch adds a _pick later.
curl now builds, with HTTP/3 disabled and patchelf on the host.
--- FR ---
package_gcc() atteignait sa toute derniere etape et s arretait sur un
seul fichier :
mv: cannot stat 'usr/lib/libgfortran.spec': No such file or directory
Le fichier existe, dans usr/lib64/libgfortran.spec. lib64 est le
MULTILIB_OSDIRNAMES par defaut de GCC pour Z en 64 bits, quand Arch
place tout dans usr/lib. Ce n est donc pas un chemin isole : toute la
disposition du paquet differe, et chaque _pick nommant usr/lib
echouerait de la meme facon.
Les arbres sont fusionnes avant le premier _pick, ce qui laisse les
definitions amont fonctionner sans retouche plutot que de reecrire
chaque chemin un a un -- et continue de tenir si Arch ajoute un _pick
plus tard.
curl se construit desormais, HTTP/3 desactive et patchelf pose sur
l hote.
Assisted-by: Claude Opus 5
2026-08-16 16:59:53 -04:00
|
|
|
|
|
|
|
|
# s390x GCC installs 64-bit libraries into usr/lib64; Arch's layout is usr/lib
|
|
|
|
|
# everywhere. package_gcc() therefore looked for files that were one directory
|
|
|
|
|
# away:
|
|
|
|
|
#
|
|
|
|
|
# mv: cannot stat 'usr/lib/libgfortran.spec': No such file or directory
|
|
|
|
|
#
|
|
|
|
|
# while the file sat in usr/lib64/libgfortran.spec. This is not one stray
|
|
|
|
|
# file -- lib64 is GCC's default MULTILIB_OSDIRNAMES for 64-bit Z, so the
|
|
|
|
|
# whole package layout is affected, and every _pick that names usr/lib would
|
|
|
|
|
# miss in the same way.
|
|
|
|
|
#
|
|
|
|
|
# The trees are merged before any _pick runs, which keeps the upstream
|
|
|
|
|
# package definitions working unchanged rather than rewriting each path.
|
|
|
|
|
python3 - <<'PY'
|
|
|
|
|
import io, re
|
|
|
|
|
s = io.open("PKGBUILD", encoding="utf-8").read()
|
|
|
|
|
merge = """ # s390x installs 64-bit libraries to lib64; Arch expects lib.
|
|
|
|
|
if [ -d usr/lib64 ]; then
|
|
|
|
|
mkdir -p usr/lib
|
|
|
|
|
cp -a usr/lib64/. usr/lib/
|
|
|
|
|
rm -rf usr/lib64
|
|
|
|
|
fi
|
|
|
|
|
"""
|
|
|
|
|
i = s.index(" _pick ")
|
|
|
|
|
s = s[:i] + merge + s[i:]
|
|
|
|
|
io.open("PKGBUILD", "w", encoding="utf-8").write(s)
|
|
|
|
|
PY
|
|
|
|
|
grep -q 'installs 64-bit libraries to lib64' PKGBUILD || {
|
|
|
|
|
echo "gcc: lib64 merge not inserted" >&2; exit 1; }
|
|
|
|
|
echo "gcc: lib64 merged into lib before packaging"
|
[FIX] gcc: 32-bit paths hidden in brace expansions; more host libraries
Two more shapes of the same multilib assumption, and the second is a
trap worth naming.
Some _pick lines write the 32-bit path in full:
mv: cannot stat 'usr/lib/gcc/s390x-ibm-linux-gnu/16/32/finclude/'
Others write BOTH paths in one line with a brace expansion --
$_libdir/{,32/}finclude/ expands to the normal path and the 32-bit one.
Deleting such a line would silently lose the path that DOES exist, so
only the alternative is removed: {,32/} and {,32} become nothing.
That distinction matters. A blanket "delete every line mentioning 32"
would have dropped gcc-fortran's finclude, libcaf and libgfortran.spec
from the package, and the loss would only have surfaced later, in
something that failed to link.
Host libraries again: libcryptsetup for util-linux, libgcrypt, libksba
and npth for gnupg, libpam for shadow.
--- FR ---
Deux formes de plus de la meme hypothese multilib, et la seconde est un
piege qui merite d etre nomme.
Certaines lignes _pick ecrivent le chemin 32 bits en entier :
mv: cannot stat 'usr/lib/gcc/s390x-ibm-linux-gnu/16/32/finclude/'
D autres ecrivent les DEUX chemins d un coup par expansion d accolades
-- $_libdir/{,32/}finclude/ produit le chemin normal et celui en 32
bits. Supprimer une telle ligne perdrait en silence le chemin qui
EXISTE, donc seule l alternative disparait : {,32/} et {,32} deviennent
rien.
La distinction compte. Un « supprimer toute ligne mentionnant 32 »
aurait retire finclude, libcaf et libgfortran.spec du paquet
gcc-fortran, et la perte ne serait apparue que plus tard, dans quelque
chose qui refuse de se lier.
Bibliotheques d hote, encore : libcryptsetup pour util-linux, libgcrypt,
libksba et npth pour gnupg, libpam pour shadow.
Assisted-by: Claude Opus 5
2026-08-16 05:19:20 -04:00
|
|
|
if grep -qE '_pick .*(\{,32|/32/)' PKGBUILD; then
|
|
|
|
|
echo "gcc: a 32-bit _pick path remains" >&2; exit 1
|
|
|
|
|
fi
|
[ADD] gcc: make libgccjit optional, strip the remaining lib32 work
Arch configures and compiles the whole gcc tree a SECOND time just for
libgccjit, because it needs --enable-host-shared and applying that to
the main compiler would slow it down. That pass is about half of gcc's
build time -- twenty minutes per attempt on this hardware -- and
nothing in the bootstrap or in ERPLibre uses it.
It is now skipped by default and restored with:
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verified both ways: off leaves zero libgccjit references in the
PKGBUILD, on leaves the ten upstream ones untouched, including the
--enable-languages=jit line the main-build sed deliberately avoids.
package_gcc() still manipulated the 32-bit tree in several places, and
each fails once multilib is off because usr/lib32 never exists:
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
The link named in that error is the one that SUCCEEDED; the failure is
the usr/lib32 line right after it in the same loop. Read alone, it
sends you hunting for a missing libatomic that is in fact present. The
same loop also linked the D runtimes, gone with the D front end.
--- FR ---
Arch configure et compile l arbre gcc entier une SECONDE fois pour le
seul libgccjit, qui reclame --enable-host-shared -- appliquer cette
option au compilateur principal le ralentirait. Cette passe represente
environ la moitie du temps de compilation de gcc, soit vingt minutes
par tentative sur cette machine, et rien dans l amorcage ni dans
ERPLibre ne s en sert.
Elle est desormais ecartee par defaut et se retablit par :
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verifie dans les deux sens : desactive, il ne reste aucune reference a
libgccjit dans le PKGBUILD ; active, les dix references amont restent
intactes, y compris la ligne --enable-languages=jit que le sed du
build principal evite deliberement.
package_gcc() manipulait encore l arbre 32 bits en plusieurs endroits,
et chacun echoue une fois le multilib retire, puisque usr/lib32
n existe jamais :
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
Le lien nomme dans cette erreur est celui qui a REUSSI ; l echec est la
ligne usr/lib32 juste apres, dans la meme boucle. Lue seule, elle fait
chercher un libatomic manquant qui est pourtant bien la. La meme boucle
liait aussi les runtimes D, partis avec le frontal D.
Assisted-by: Claude Opus 5
2026-08-16 01:54:13 -04:00
|
|
|
|
|
|
|
|
# The same loop links the D runtimes, which do not exist now that the D
|
|
|
|
|
# front end is off.
|
|
|
|
|
sed -i 's/^\(\s*for _so in \).*; do$/\1libatomic.so libstdc++.so; do/' PKGBUILD
|
|
|
|
|
|
[FIX] clean the source tree between attempts; strip gcc _pick lines
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
2026-08-16 02:23:01 -04:00
|
|
|
# package_gcc() also _picks files out for every sub-package, including the
|
|
|
|
|
# front ends we disabled. _pick is a mv, so it fails on what was never built:
|
|
|
|
|
#
|
|
|
|
|
# mv: cannot stat 'usr/bin/gnat': No such file or directory
|
|
|
|
|
#
|
|
|
|
|
# Dropping the entries from pkgname was not enough -- the _pick lines live in
|
|
|
|
|
# package_gcc() and run regardless of which sub-packages are requested.
|
[FIX] gcc: libquadmath does not exist on s390x; python alias for util-linux
mv: cannot stat 'usr/lib/libquadmath.a': No such file or directory
libquadmath implements __float128, which exists on x86 and ia64. On
s390x the directory is CONFIGURED -- it holds a Makefile, a config.log
and a config.status -- but no library is ever built. The half-created
directory is what makes this one confusing: it looks like a build that
failed rather than a target that has nothing to build.
Dropped from pkgname, from the _pick lines, and from the depends entry
in another sub-package. That last one matters: with --nodeps it is
harmless at build time and fatal at install time, which is exactly the
kind of defect that surfaces long after the build that introduced it.
package_libquadmath() is left in place. makepkg never calls a function
whose name is absent from pkgname, so removing it would be churn.
util-linux calls "python", which Ubuntu does not provide -- only
python3. python-is-python3 supplies the name.
--- FR ---
mv: cannot stat 'usr/lib/libquadmath.a': No such file or directory
libquadmath implemente __float128, qui existe sur x86 et ia64. Sur
s390x le repertoire est CONFIGURE -- il contient un Makefile, un
config.log et un config.status -- mais aucune bibliotheque n y est
jamais batie. C est ce repertoire a moitie cree qui rend le cas
trompeur : il a l air d une compilation ratee plutot que d une cible
qui n a rien a construire.
Retire de pkgname, des lignes _pick, et de la declaration depends d un
autre sous-paquet. Ce dernier point compte : avec --nodeps il est
inoffensif a la compilation et fatal a l installation, exactement le
genre de defaut qui se revele longtemps apres la compilation qui l a
introduit.
package_libquadmath() reste en place. makepkg n appelle jamais une
fonction dont le nom est absent de pkgname ; la retirer serait du
bruit.
util-linux appelle « python », qu Ubuntu ne fournit pas -- seulement
python3. python-is-python3 fournit le nom.
Assisted-by: Claude Opus 5
2026-08-16 19:52:55 -04:00
|
|
|
for _lang in gcc-ada gcc-d gcc-go gcc-m2 gcc-rust gcc-gcobol libquadmath \
|
[FIX] clean the source tree between attempts; strip gcc _pick lines
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
2026-08-16 02:23:01 -04:00
|
|
|
libgm2 libgo libgphobos libgcobol libhwasan; do
|
|
|
|
|
sed -i "/_pick ${_lang} /d" PKGBUILD
|
|
|
|
|
done
|
|
|
|
|
if grep -qE '_pick (gcc-ada|gcc-d|gcc-go|gcc-m2|gcc-rust|gcc-gcobol) ' PKGBUILD; then
|
|
|
|
|
echo "gcc: _pick lines remain for a disabled front end" >&2; exit 1
|
|
|
|
|
fi
|
|
|
|
|
|
[ADD] gcc: make libgccjit optional, strip the remaining lib32 work
Arch configures and compiles the whole gcc tree a SECOND time just for
libgccjit, because it needs --enable-host-shared and applying that to
the main compiler would slow it down. That pass is about half of gcc's
build time -- twenty minutes per attempt on this hardware -- and
nothing in the bootstrap or in ERPLibre uses it.
It is now skipped by default and restored with:
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verified both ways: off leaves zero libgccjit references in the
PKGBUILD, on leaves the ten upstream ones untouched, including the
--enable-languages=jit line the main-build sed deliberately avoids.
package_gcc() still manipulated the 32-bit tree in several places, and
each fails once multilib is off because usr/lib32 never exists:
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
The link named in that error is the one that SUCCEEDED; the failure is
the usr/lib32 line right after it in the same loop. Read alone, it
sends you hunting for a missing libatomic that is in fact present. The
same loop also linked the D runtimes, gone with the D front end.
--- FR ---
Arch configure et compile l arbre gcc entier une SECONDE fois pour le
seul libgccjit, qui reclame --enable-host-shared -- appliquer cette
option au compilateur principal le ralentirait. Cette passe represente
environ la moitie du temps de compilation de gcc, soit vingt minutes
par tentative sur cette machine, et rien dans l amorcage ni dans
ERPLibre ne s en sert.
Elle est desormais ecartee par defaut et se retablit par :
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verifie dans les deux sens : desactive, il ne reste aucune reference a
libgccjit dans le PKGBUILD ; active, les dix references amont restent
intactes, y compris la ligne --enable-languages=jit que le sed du
build principal evite deliberement.
package_gcc() manipulait encore l arbre 32 bits en plusieurs endroits,
et chacun echoue une fois le multilib retire, puisque usr/lib32
n existe jamais :
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
Le lien nomme dans cette erreur est celui qui a REUSSI ; l echec est la
ligne usr/lib32 juste apres, dans la meme boucle. Lue seule, elle fait
chercher un libatomic manquant qui est pourtant bien la. La meme boucle
liait aussi les runtimes D, partis avec le frontal D.
Assisted-by: Claude Opus 5
2026-08-16 01:54:13 -04:00
|
|
|
if grep -q 'usr/lib32' PKGBUILD; then
|
|
|
|
|
echo "gcc: usr/lib32 still manipulated" >&2; exit 1
|
|
|
|
|
fi
|
|
|
|
|
if grep -qE 'for _so in .*(gdruntime|gphobos)' PKGBUILD; then
|
|
|
|
|
echo "gcc: D runtimes still in the symlink loop" >&2; exit 1
|
|
|
|
|
fi
|
|
|
|
|
grep -m1 'for _so in' PKGBUILD | sed 's/^\s*//'
|
|
|
|
|
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
# Verify what matters: the array makepkg iterates. Grepping the whole file
|
|
|
|
|
# for the bare name declared a false failure once already, on libtool and
|
|
|
|
|
# then here -- the string survives in comments and in unused functions.
|
|
|
|
|
if sed -n '/^pkgname=(/,/^)/p' PKGBUILD | grep -q 'lib32'; then
|
|
|
|
|
echo "gcc: lib32 still in pkgname array" >&2; exit 1
|
|
|
|
|
fi
|
[ADD] port patches: gcc front ends, binutils gold, libtool multilib
Three more upstream PKGBUILDs assume x86_64, each in a different way,
and each is dropped rather than repaired because the thing being
dropped is architecture-specific by nature.
gcc: Ada and D are written in themselves and need an existing compiler
of the same language. Ubuntu ships gnat, but not one GCC 15 accepts,
and there is no D bootstrap compiler here at all. Modula-2 and COBOL
have the same shape. Front ends reduced to c, c++, fortran, lto, objc
and obj-c++, which is everything this port and ERPLibre compile.
binutils: gold is x86-centric, deprecated upstream since 2.44, and
built by no distribution that ships s390x. ld.bfd is the linker on Z.
binutils builds once gold is disabled -- measured.
libtool: the lib32-libltdl split package is i686-on-x86_64 multilib.
Its build step is already guarded by CARCH, but prepare() copies the
tree to src/libtool32 unconditionally and the package function then
packages a tree nobody built.
Two host-layout bridges were also needed. Ubuntu multiarch puts asm/,
bits/, gnu/ and sys/sdt.h under /usr/include/s390x-linux-gnu, while
glibc builds with -nostdinc and expects the classic layout:
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Symlinks make the host look like Arch for those paths. sys/ needed the
files linked, not the directory, since /usr/include/sys already exists.
--- FR ---
Trois PKGBUILD amont de plus supposent x86_64, chacun a sa maniere, et
chacun est retire plutot que repare : ce qu on retire est par nature
propre a une architecture.
gcc : Ada et D sont ecrits en eux-memes et reclament un compilateur
existant du meme langage. Ubuntu livre gnat, mais pas une version que
GCC 15 accepte, et il n y a ici aucun compilateur D d amorcage.
Modula-2 et COBOL posent le meme probleme. Les frontaux se reduisent a
c, c++, fortran, lto, objc et obj-c++, ce qui couvre tout ce que ce
portage et ERPLibre compilent.
binutils : gold est centre sur x86, abandonne en amont depuis 2.44, et
construit par aucune distribution livrant s390x. Sur Z, l editeur de
liens est ld.bfd. binutils se construit des que gold est desactive --
mesure.
libtool : le paquet scinde lib32-libltdl est du multilib i686 sur
x86_64. Son etape de compilation est deja gardee par CARCH, mais
prepare() copie l arbre vers src/libtool32 sans condition, et la
fonction de paquet empaquette ensuite un arbre que personne n a bati.
Deux ponts de disposition d hote etaient aussi necessaires. Le
multiarch d Ubuntu place asm/, bits/, gnu/ et sys/sdt.h sous
/usr/include/s390x-linux-gnu, quand glibc compile avec -nostdinc et
attend la disposition classique :
fatal error: asm/errno.h: No such file or directory
fatal error: sys/sdt.h: No such file or directory
Des liens symboliques donnent a l hote l allure d Arch pour ces
chemins. Pour sys/ il faut lier les fichiers et non le repertoire,
puisque /usr/include/sys existe deja.
Assisted-by: Claude Opus 5
2026-08-15 21:01:18 -04:00
|
|
|
grep -m1 -- '--enable-languages' PKGBUILD
|
[ADD] gcc: make libgccjit optional, strip the remaining lib32 work
Arch configures and compiles the whole gcc tree a SECOND time just for
libgccjit, because it needs --enable-host-shared and applying that to
the main compiler would slow it down. That pass is about half of gcc's
build time -- twenty minutes per attempt on this hardware -- and
nothing in the bootstrap or in ERPLibre uses it.
It is now skipped by default and restored with:
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verified both ways: off leaves zero libgccjit references in the
PKGBUILD, on leaves the ten upstream ones untouched, including the
--enable-languages=jit line the main-build sed deliberately avoids.
package_gcc() still manipulated the 32-bit tree in several places, and
each fails once multilib is off because usr/lib32 never exists:
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
The link named in that error is the one that SUCCEEDED; the failure is
the usr/lib32 line right after it in the same loop. Read alone, it
sends you hunting for a missing libatomic that is in fact present. The
same loop also linked the D runtimes, gone with the D front end.
--- FR ---
Arch configure et compile l arbre gcc entier une SECONDE fois pour le
seul libgccjit, qui reclame --enable-host-shared -- appliquer cette
option au compilateur principal le ralentirait. Cette passe represente
environ la moitie du temps de compilation de gcc, soit vingt minutes
par tentative sur cette machine, et rien dans l amorcage ni dans
ERPLibre ne s en sert.
Elle est desormais ecartee par defaut et se retablit par :
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verifie dans les deux sens : desactive, il ne reste aucune reference a
libgccjit dans le PKGBUILD ; active, les dix references amont restent
intactes, y compris la ligne --enable-languages=jit que le sed du
build principal evite deliberement.
package_gcc() manipulait encore l arbre 32 bits en plusieurs endroits,
et chacun echoue une fois le multilib retire, puisque usr/lib32
n existe jamais :
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
Le lien nomme dans cette erreur est celui qui a REUSSI ; l echec est la
ligne usr/lib32 juste apres, dans la meme boucle. Lue seule, elle fait
chercher un libatomic manquant qui est pourtant bien la. La meme boucle
liait aussi les runtimes D, partis avec le frontal D.
Assisted-by: Claude Opus 5
2026-08-16 01:54:13 -04:00
|
|
|
|
|
|
|
|
# libgccjit: OPTIONAL, and off by default.
|
|
|
|
|
#
|
|
|
|
|
# Arch configures and compiles the entire gcc source tree a SECOND time just
|
|
|
|
|
# for libgccjit -- it needs --enable-host-shared, which would slow the main
|
|
|
|
|
# compiler down if applied to it. That second pass is roughly half of gcc's
|
|
|
|
|
# build time, and on this hardware that is twenty minutes per attempt.
|
|
|
|
|
#
|
|
|
|
|
# Nothing in the bootstrap needs it, and neither does ERPLibre. It is
|
|
|
|
|
# skipped by default and re-enabled with:
|
|
|
|
|
#
|
|
|
|
|
# EL_GCC_JIT=1 bash scripts/build-stage1.sh
|
|
|
|
|
#
|
|
|
|
|
# When enabled, nothing below runs and the PKGBUILD keeps its upstream
|
|
|
|
|
# behaviour, including the --enable-languages=jit line the main-build sed
|
|
|
|
|
# deliberately leaves alone.
|
|
|
|
|
if [ "${EL_GCC_JIT:-0}" != "1" ]; then
|
|
|
|
|
python3 - <<'PY'
|
|
|
|
|
import io, re
|
|
|
|
|
s = io.open("PKGBUILD", encoding="utf-8").read()
|
|
|
|
|
# The second configure pass, from its comment to the copy of the .so.
|
|
|
|
|
s = re.sub(
|
|
|
|
|
r"\n # Build libgccjit separately.*?\n cp -a gcc/libgccjit\.so\* \.\./gcc-build/gcc/\n",
|
|
|
|
|
"\n", s, flags=re.S)
|
|
|
|
|
# Its package function, the _pick lines that feed it, and its pkgname entry.
|
|
|
|
|
s = re.sub(r"\npackage_libgccjit\(\)\s*\{.*?\n\}\n", "\n", s, flags=re.S)
|
|
|
|
|
s = "\n".join(l for l in s.split("\n")
|
|
|
|
|
if "_pick libgccjit" not in l
|
|
|
|
|
and l.strip() != "libgccjit"
|
|
|
|
|
and "mkdir -p \"$srcdir\"/libgccjit-build" not in l)
|
|
|
|
|
io.open("PKGBUILD", "w", encoding="utf-8").write(s)
|
|
|
|
|
PY
|
[FIX] gcc: remove the explicit jit install; libpam for shadow and util-linux
Disabling libgccjit took four separate cuts, and this is the fourth.
Removing the second configure pass, the pkgname entry and the _pick
lines still left package_gcc() calling
make -C gcc DESTDIR="$pkgdir" jit.install-common jit.install-info
which fails on a library that was never built:
install: cannot install libgccjit.so.0.0.1
The lesson repeats: in an Arch PKGBUILD a component is referenced in
several independent places -- the pkgname array, a build block, _pick
lines in package(), and explicit make targets. Removing it means
finding all four, and grepping for the component name after each cut is
the only way to know.
shadow and util-linux both stop on a missing libpam. Same family as
every host makedepend before them: invisible until a build names it,
because --nodeps forbids pacman from checking.
--- FR ---
Desactiver libgccjit aura demande quatre coupes distinctes, et voici la
quatrieme. Retirer la seconde passe de configuration, l entree de
pkgname et les lignes _pick laissait encore package_gcc() appeler
make -C gcc DESTDIR="$pkgdir" jit.install-common jit.install-info
qui echoue sur une bibliotheque jamais batie :
install: cannot install libgccjit.so.0.0.1
La lecon se repete : dans un PKGBUILD d Arch, un composant est
reference en plusieurs endroits independants -- le tableau pkgname, un
bloc de compilation, des lignes _pick dans package(), et des cibles
make explicites. Le retirer suppose de trouver les quatre, et chercher
son nom apres chaque coupe est le seul moyen de le savoir.
shadow et util-linux s arretent tous deux sur un libpam absent. Meme
famille que tous les makedepends d hote precedents : invisibles jusqu a
ce qu une compilation les nomme, puisque --nodeps interdit a pacman de
verifier.
Assisted-by: Claude Opus 5
2026-08-16 03:57:46 -04:00
|
|
|
# package_gcc() also installs the jit artefacts explicitly:
|
|
|
|
|
# make -C gcc DESTDIR="$pkgdir" jit.install-common jit.install-info
|
|
|
|
|
# Removing the build block and the pkgname entry was not enough --
|
|
|
|
|
# this line runs in the MAIN package function and fails on a library
|
|
|
|
|
# that was never built:
|
|
|
|
|
# install: cannot install libgccjit.so.0.0.1
|
|
|
|
|
sed -i '/jit\.install-common/d' PKGBUILD
|
[ADD] gcc: make libgccjit optional, strip the remaining lib32 work
Arch configures and compiles the whole gcc tree a SECOND time just for
libgccjit, because it needs --enable-host-shared and applying that to
the main compiler would slow it down. That pass is about half of gcc's
build time -- twenty minutes per attempt on this hardware -- and
nothing in the bootstrap or in ERPLibre uses it.
It is now skipped by default and restored with:
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verified both ways: off leaves zero libgccjit references in the
PKGBUILD, on leaves the ten upstream ones untouched, including the
--enable-languages=jit line the main-build sed deliberately avoids.
package_gcc() still manipulated the 32-bit tree in several places, and
each fails once multilib is off because usr/lib32 never exists:
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
The link named in that error is the one that SUCCEEDED; the failure is
the usr/lib32 line right after it in the same loop. Read alone, it
sends you hunting for a missing libatomic that is in fact present. The
same loop also linked the D runtimes, gone with the D front end.
--- FR ---
Arch configure et compile l arbre gcc entier une SECONDE fois pour le
seul libgccjit, qui reclame --enable-host-shared -- appliquer cette
option au compilateur principal le ralentirait. Cette passe represente
environ la moitie du temps de compilation de gcc, soit vingt minutes
par tentative sur cette machine, et rien dans l amorcage ni dans
ERPLibre ne s en sert.
Elle est desormais ecartee par defaut et se retablit par :
EL_GCC_JIT=1 bash scripts/build-stage1.sh
Verifie dans les deux sens : desactive, il ne reste aucune reference a
libgccjit dans le PKGBUILD ; active, les dix references amont restent
intactes, y compris la ligne --enable-languages=jit que le sed du
build principal evite deliberement.
package_gcc() manipulait encore l arbre 32 bits en plusieurs endroits,
et chacun echoue une fois le multilib retire, puisque usr/lib32
n existe jamais :
'usr/lib/gcc/s390x-ibm-linux-gnu/16/libatomic.so' -> '../../../libatomic.so'
ln: No such file or directory
Le lien nomme dans cette erreur est celui qui a REUSSI ; l echec est la
ligne usr/lib32 juste apres, dans la meme boucle. Lue seule, elle fait
chercher un libatomic manquant qui est pourtant bien la. La meme boucle
liait aussi les runtimes D, partis avec le frontal D.
Assisted-by: Claude Opus 5
2026-08-16 01:54:13 -04:00
|
|
|
if grep -q 'libgccjit-build' PKGBUILD; then
|
|
|
|
|
echo "gcc: libgccjit build block remains" >&2; exit 1
|
|
|
|
|
fi
|
|
|
|
|
if sed -n '/^pkgname=(/,/^)/p' PKGBUILD | grep -q 'libgccjit'; then
|
|
|
|
|
echo "gcc: libgccjit still in pkgname array" >&2; exit 1
|
|
|
|
|
fi
|
|
|
|
|
echo "gcc: libgccjit skipped (set EL_GCC_JIT=1 to build it)"
|
|
|
|
|
else
|
|
|
|
|
echo "gcc: libgccjit ENABLED (second full build of the tree)"
|
|
|
|
|
fi
|
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc
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
2026-08-15 21:15:01 -04:00
|
|
|
echo "gcc: front ends reduced, multilib off, lib32 removed"
|
[FIX] gcc: bound bootstrap parallelism; libmagic and patchelf on the host
gcc failed on what looked like a missing header:
/usr/include/strings.h:23:10: fatal error:
.../gcc-build/prev-gcc/include/stddef.h: No such file or directory
The file was PRESENT when the tree was inspected afterwards. It is not
missing: it is generated by a rule that another rule consumes without
declaring the dependency, and with MAKEFLAGS=-j16 sixteen jobs win that
race often enough to fail. Read as an absent header, it sends you
hunting through include paths for nothing -- and past a set of host
symlinks that were, this time, innocent.
The bound goes into build() inside the PKGBUILD. My first attempt
exported MAKEFLAGS from the hook, which cannot work: hooks run in their
own bash process and never reach makepkg. gcc is the only package here
that bootstraps itself three times, so the limit is local to it.
util-linux wanted libmagic; curl wanted patchelf. Both installed.
--- FR ---
gcc echouait sur ce qui ressemblait a un en-tete manquant :
/usr/include/strings.h:23:10: fatal error:
.../gcc-build/prev-gcc/include/stddef.h: No such file or directory
Le fichier etait PRESENT a l inspection de l arbre apres coup. Il ne
manque pas : il est produit par une regle qu une autre consomme sans
declarer la dependance, et avec MAKEFLAGS=-j16 seize taches gagnent
cette course assez souvent pour echouer. Lu comme un en-tete absent, il
fait fouiller les chemins d inclusion pour rien -- et soupconner des
liens symboliques d hote qui, cette fois, etaient innocents.
La borne va dans build(), a l interieur du PKGBUILD. Ma premiere
tentative exportait MAKEFLAGS depuis le crochet, ce qui ne peut pas
fonctionner : les crochets tournent dans leur propre processus bash et
n atteignent jamais makepkg. gcc est le seul paquet ici a s amorcer
trois fois, la limite lui reste donc locale.
util-linux reclamait libmagic ; curl reclamait patchelf. Poses tous deux.
Assisted-by: Claude Opus 5
2026-08-16 07:13:33 -04:00
|
|
|
# Bound the parallelism of gcc's own bootstrap, INSIDE the PKGBUILD.
|
|
|
|
|
#
|
|
|
|
|
# With MAKEFLAGS=-j16 the stage-2 bootstrap raced against itself:
|
|
|
|
|
#
|
|
|
|
|
# /usr/include/strings.h:23:10: fatal error:
|
|
|
|
|
# .../gcc-build/prev-gcc/include/stddef.h: No such file or directory
|
|
|
|
|
#
|
|
|
|
|
# The file was PRESENT when the tree was inspected afterwards. It is not
|
|
|
|
|
# missing -- it is generated by a rule another rule consumes without
|
|
|
|
|
# declaring the dependency, and sixteen jobs win that race often enough to
|
|
|
|
|
# fail. Read as an absent header, it sends you hunting through include paths
|
|
|
|
|
# for nothing.
|
|
|
|
|
#
|
|
|
|
|
# The setting has to go into build(): this hook runs in its own bash process,
|
|
|
|
|
# so exporting MAKEFLAGS here would never reach makepkg. gcc is the only
|
|
|
|
|
# package in the list that bootstraps itself three times, so the bound is
|
|
|
|
|
# applied here rather than globally.
|
|
|
|
|
sed -i '0,/^build() {$/s//build() {\n export MAKEFLAGS="-j8"/' PKGBUILD
|
|
|
|
|
grep -A1 '^build() {' PKGBUILD | head -2 | sed 's/^/ /'
|
[FIX] gcc: libquadmath does not exist on s390x; python alias for util-linux
mv: cannot stat 'usr/lib/libquadmath.a': No such file or directory
libquadmath implements __float128, which exists on x86 and ia64. On
s390x the directory is CONFIGURED -- it holds a Makefile, a config.log
and a config.status -- but no library is ever built. The half-created
directory is what makes this one confusing: it looks like a build that
failed rather than a target that has nothing to build.
Dropped from pkgname, from the _pick lines, and from the depends entry
in another sub-package. That last one matters: with --nodeps it is
harmless at build time and fatal at install time, which is exactly the
kind of defect that surfaces long after the build that introduced it.
package_libquadmath() is left in place. makepkg never calls a function
whose name is absent from pkgname, so removing it would be churn.
util-linux calls "python", which Ubuntu does not provide -- only
python3. python-is-python3 supplies the name.
--- FR ---
mv: cannot stat 'usr/lib/libquadmath.a': No such file or directory
libquadmath implemente __float128, qui existe sur x86 et ia64. Sur
s390x le repertoire est CONFIGURE -- il contient un Makefile, un
config.log et un config.status -- mais aucune bibliotheque n y est
jamais batie. C est ce repertoire a moitie cree qui rend le cas
trompeur : il a l air d une compilation ratee plutot que d une cible
qui n a rien a construire.
Retire de pkgname, des lignes _pick, et de la declaration depends d un
autre sous-paquet. Ce dernier point compte : avec --nodeps il est
inoffensif a la compilation et fatal a l installation, exactement le
genre de defaut qui se revele longtemps apres la compilation qui l a
introduit.
package_libquadmath() reste en place. makepkg n appelle jamais une
fonction dont le nom est absent de pkgname ; la retirer serait du
bruit.
util-linux appelle « python », qu Ubuntu ne fournit pas -- seulement
python3. python-is-python3 fournit le nom.
Assisted-by: Claude Opus 5
2026-08-16 19:52:55 -04:00
|
|
|
|
[FIX] gcc: a dropped component is removed in a fifth place
The repository already knew four: pkgname, the build block, the _pick
lines, the explicit make targets. There is a fifth, and it is the only one
that fails silently -- the depends= array of a DIFFERENT sub-package.
--nodeps means makepkg never checks, so gcc-libs built, passed, and went
into the repository declaring a dependency on libhwasan, which this
architecture never produces. Nothing said a word. pacman did, the first
time anything tried to install it:
:: unable to satisfy dependency 'libhwasan' required by gcc-libs
This was already paid for once: an earlier pass hit it with libquadmath and
pruned that one name by hand. libhwasan joined the drop set afterwards and
the pruning was not extended. Pruning one name at a time was the bug.
The set that decides what is not built now also decides what is not
depended on, and an assertion refuses to let the two drift again.
--- FR ---
Le dépôt en connaissait déjà quatre : pkgname, le bloc de build, les lignes
_pick, les cibles make explicites. Il y en a un cinquième, et c'est le seul
qui échoue en silence — le tableau depends= d'un AUTRE sous-paquet.
--nodeps veut dire que makepkg ne vérifie jamais : gcc-libs s'est construit,
a été accepté, et est entré dans le dépôt en déclarant une dépendance envers
libhwasan, que cette architecture ne produit jamais. Rien n'a bronché.
pacman, si, à la première tentative d'installation :
:: unable to satisfy dependency 'libhwasan' required by gcc-libs
C'était déjà payé une fois : un passage antérieur avait rencontré le piège
avec libquadmath et élagué ce seul nom à la main. libhwasan a rejoint la
liste des retraits ensuite, sans que l'élagage suive. Élaguer nom par nom
était le vrai défaut.
L'ensemble qui décide de ce qui n'est pas construit décide désormais aussi
de ce dont on ne dépend pas, et une assertion interdit aux deux de diverger.
Assisted-by: Claude Opus 5
2026-08-17 02:37:46 -04:00
|
|
|
# THE FIFTH PLACE. The repository already knew a component is removed in four
|
|
|
|
|
# independent places -- pkgname, the build block, the _pick lines and the
|
|
|
|
|
# explicit make targets. There is a fifth: the depends= array of a DIFFERENT
|
|
|
|
|
# sub-package.
|
|
|
|
|
#
|
|
|
|
|
# It is the only one that fails silently. --nodeps means makepkg never checks,
|
|
|
|
|
# so the build succeeds and the package goes into the repository declaring a
|
|
|
|
|
# dependency on something this architecture will never produce. Nothing says a
|
|
|
|
|
# word until an install is attempted, which for a bootstrap is much later:
|
|
|
|
|
#
|
|
|
|
|
# :: unable to satisfy dependency 'libhwasan' required by gcc-libs
|
|
|
|
|
#
|
|
|
|
|
# This was already paid for once. A previous pass hit it with libquadmath and
|
|
|
|
|
# pruned that one name by hand; libhwasan was added to the drop set afterwards
|
|
|
|
|
# and the pruning was not extended, so gcc-libs shipped uninstallable. Pruning
|
|
|
|
|
# one name at a time is the bug, not the missing name.
|
|
|
|
|
#
|
|
|
|
|
# So the same `drop` set that decides what is NOT built now also decides what
|
|
|
|
|
# is not depended on, and the check below asserts it rather than trusting it.
|
|
|
|
|
# Adding a name to that set is now enough, in one place.
|
|
|
|
|
#
|
[FIX] declared, never linked: guile, libisl.so, leancrypto
An audit of every missing dependency spelled as a soname, asking the ARTEFACT
whether the package that declares it actually links it. It contradicted my
guesses: curl's krb5, ssh2 and idn2 are all real. Two were not.
make readelf -d usr/bin/make -> libc.so.6, and nothing else
gcc configure recorded ISLLIBS='' ISLINC=''; zero libisl in the tree
Both are false in our build environment and true in Arch's. --nodeps means
makepkg never checks, so each shipped a package asking for something this
port will never contain -- and only pacman ever notices, at install time.
Building isl was the first plan. Its Arch packaging repo was last touched in
2017 and its only source URL is isl.gforge.inria.fr, dead with INRIA's
GForge. There is nothing to build; the declaration goes instead, and Graphite
goes with it.
gnutls found the same shape from the other direction: --with-leancrypto
stopped configure, and 'leancrypto' sat in depends= where nothing checks it.
--- FR ---
Un audit de chaque dépendance manquante écrite en soname, demandant à
l'ARTEFACT si le paquet qui la déclare la lie vraiment. Il a contredit mes
suppositions : les krb5, ssh2 et idn2 de curl sont bien réels. Deux ne
l'étaient pas.
make readelf -d usr/bin/make -> libc.so.6, et rien d'autre
gcc configure a noté ISLLIBS='' ISLINC='' ; aucun libisl dans l'arbre
Les deux sont fausses dans notre environnement et vraies dans celui d'Arch.
--nodeps veut dire que makepkg ne vérifie jamais : chacun livrait donc un
paquet réclamant ce que ce portage ne contiendra jamais — et seul pacman s'en
aperçoit, à l'installation.
Bâtir isl était le premier plan. Son dépôt de packaging Arch n'a pas bougé
depuis 2017 et sa seule source pointe isl.gforge.inria.fr, morte avec le
GForge d'INRIA. Il n'y a rien à bâtir : c'est la déclaration qui part, et
Graphite avec elle.
gnutls a montré la même forme par l'autre bout : --with-leancrypto arrêtait
configure, et 'leancrypto' figurait dans depends= où rien ne le vérifie.
Assisted-by: Claude Opus 5
2026-08-19 05:28:32 -04:00
|
|
|
# libisl.so is in the same list for a DIFFERENT reason, and the difference is
|
|
|
|
|
# worth a sentence. The others are components this PKGBUILD stops building.
|
|
|
|
|
# isl is an outside library that gcc simply never linked: the host has no isl,
|
|
|
|
|
# so configure recorded ISLLIBS='' and ISLINC='', and the artefact agrees --
|
|
|
|
|
#
|
|
|
|
|
# $ readelf -d usr/bin/gcc usr/lib/libgcc_s.so.1 | grep -c libisl
|
|
|
|
|
# 0
|
|
|
|
|
#
|
|
|
|
|
# The remedy is the same, so the list is the same. Building isl instead was
|
|
|
|
|
# the first plan and it does not work: the Arch packaging repo for isl was
|
|
|
|
|
# last touched in 2017 and its only source URL is isl.gforge.inria.fr, which
|
|
|
|
|
# died with INRIA's GForge. What this costs is Graphite -- the -floop-*
|
|
|
|
|
# optimisations -- and TODO.md records it.
|
|
|
|
|
#
|
[FIX] gcc: a dropped component is removed in a fifth place
The repository already knew four: pkgname, the build block, the _pick
lines, the explicit make targets. There is a fifth, and it is the only one
that fails silently -- the depends= array of a DIFFERENT sub-package.
--nodeps means makepkg never checks, so gcc-libs built, passed, and went
into the repository declaring a dependency on libhwasan, which this
architecture never produces. Nothing said a word. pacman did, the first
time anything tried to install it:
:: unable to satisfy dependency 'libhwasan' required by gcc-libs
This was already paid for once: an earlier pass hit it with libquadmath and
pruned that one name by hand. libhwasan joined the drop set afterwards and
the pruning was not extended. Pruning one name at a time was the bug.
The set that decides what is not built now also decides what is not
depended on, and an assertion refuses to let the two drift again.
--- FR ---
Le dépôt en connaissait déjà quatre : pkgname, le bloc de build, les lignes
_pick, les cibles make explicites. Il y en a un cinquième, et c'est le seul
qui échoue en silence — le tableau depends= d'un AUTRE sous-paquet.
--nodeps veut dire que makepkg ne vérifie jamais : gcc-libs s'est construit,
a été accepté, et est entré dans le dépôt en déclarant une dépendance envers
libhwasan, que cette architecture ne produit jamais. Rien n'a bronché.
pacman, si, à la première tentative d'installation :
:: unable to satisfy dependency 'libhwasan' required by gcc-libs
C'était déjà payé une fois : un passage antérieur avait rencontré le piège
avec libquadmath et élagué ce seul nom à la main. libhwasan a rejoint la
liste des retraits ensuite, sans que l'élagage suive. Élaguer nom par nom
était le vrai défaut.
L'ensemble qui décide de ce qui n'est pas construit décide désormais aussi
de ce dont on ne dépend pas, et une assertion interdit aux deux de diverger.
Assisted-by: Claude Opus 5
2026-08-17 02:37:46 -04:00
|
|
|
# Both spellings occur: a bare name in a sub-package's depends, and the
|
|
|
|
|
# versioned "libhwasan=$pkgver-$pkgrel" form in gcc's own. The unused
|
|
|
|
|
# package_libhwasan() function can stay -- makepkg never calls a function
|
|
|
|
|
# whose name is absent from pkgname.
|
|
|
|
|
python3 - <<'PY'
|
|
|
|
|
import io, re
|
|
|
|
|
drop = ["libhwasan", "libquadmath", "lib32-gcc-libs",
|
[FIX] declared, never linked: guile, libisl.so, leancrypto
An audit of every missing dependency spelled as a soname, asking the ARTEFACT
whether the package that declares it actually links it. It contradicted my
guesses: curl's krb5, ssh2 and idn2 are all real. Two were not.
make readelf -d usr/bin/make -> libc.so.6, and nothing else
gcc configure recorded ISLLIBS='' ISLINC=''; zero libisl in the tree
Both are false in our build environment and true in Arch's. --nodeps means
makepkg never checks, so each shipped a package asking for something this
port will never contain -- and only pacman ever notices, at install time.
Building isl was the first plan. Its Arch packaging repo was last touched in
2017 and its only source URL is isl.gforge.inria.fr, dead with INRIA's
GForge. There is nothing to build; the declaration goes instead, and Graphite
goes with it.
gnutls found the same shape from the other direction: --with-leancrypto
stopped configure, and 'leancrypto' sat in depends= where nothing checks it.
--- FR ---
Un audit de chaque dépendance manquante écrite en soname, demandant à
l'ARTEFACT si le paquet qui la déclare la lie vraiment. Il a contredit mes
suppositions : les krb5, ssh2 et idn2 de curl sont bien réels. Deux ne
l'étaient pas.
make readelf -d usr/bin/make -> libc.so.6, et rien d'autre
gcc configure a noté ISLLIBS='' ISLINC='' ; aucun libisl dans l'arbre
Les deux sont fausses dans notre environnement et vraies dans celui d'Arch.
--nodeps veut dire que makepkg ne vérifie jamais : chacun livrait donc un
paquet réclamant ce que ce portage ne contiendra jamais — et seul pacman s'en
aperçoit, à l'installation.
Bâtir isl était le premier plan. Son dépôt de packaging Arch n'a pas bougé
depuis 2017 et sa seule source pointe isl.gforge.inria.fr, morte avec le
GForge d'INRIA. Il n'y a rien à bâtir : c'est la déclaration qui part, et
Graphite avec elle.
gnutls a montré la même forme par l'autre bout : --with-leancrypto arrêtait
configure, et 'leancrypto' figurait dans depends= où rien ne le vérifie.
Assisted-by: Claude Opus 5
2026-08-19 05:28:32 -04:00
|
|
|
"libgm2", "libgo", "libgphobos", "libgcobol",
|
|
|
|
|
# Not a component we dropped -- an EXTERNAL library gcc was never
|
|
|
|
|
# configured against. See the note above the list.
|
|
|
|
|
"libisl.so"]
|
[FIX] gcc: a dropped component is removed in a fifth place
The repository already knew four: pkgname, the build block, the _pick
lines, the explicit make targets. There is a fifth, and it is the only one
that fails silently -- the depends= array of a DIFFERENT sub-package.
--nodeps means makepkg never checks, so gcc-libs built, passed, and went
into the repository declaring a dependency on libhwasan, which this
architecture never produces. Nothing said a word. pacman did, the first
time anything tried to install it:
:: unable to satisfy dependency 'libhwasan' required by gcc-libs
This was already paid for once: an earlier pass hit it with libquadmath and
pruned that one name by hand. libhwasan joined the drop set afterwards and
the pruning was not extended. Pruning one name at a time was the bug.
The set that decides what is not built now also decides what is not
depended on, and an assertion refuses to let the two drift again.
--- FR ---
Le dépôt en connaissait déjà quatre : pkgname, le bloc de build, les lignes
_pick, les cibles make explicites. Il y en a un cinquième, et c'est le seul
qui échoue en silence — le tableau depends= d'un AUTRE sous-paquet.
--nodeps veut dire que makepkg ne vérifie jamais : gcc-libs s'est construit,
a été accepté, et est entré dans le dépôt en déclarant une dépendance envers
libhwasan, que cette architecture ne produit jamais. Rien n'a bronché.
pacman, si, à la première tentative d'installation :
:: unable to satisfy dependency 'libhwasan' required by gcc-libs
C'était déjà payé une fois : un passage antérieur avait rencontré le piège
avec libquadmath et élagué ce seul nom à la main. libhwasan a rejoint la
liste des retraits ensuite, sans que l'élagage suive. Élaguer nom par nom
était le vrai défaut.
L'ensemble qui décide de ce qui n'est pas construit décide désormais aussi
de ce dont on ne dépend pas, et une assertion interdit aux deux de diverger.
Assisted-by: Claude Opus 5
2026-08-17 02:37:46 -04:00
|
|
|
s = io.open("PKGBUILD", encoding="utf-8").read()
|
|
|
|
|
|
|
|
|
|
def prune(block):
|
|
|
|
|
out = []
|
|
|
|
|
for ln in block.splitlines(True):
|
|
|
|
|
bare = ln.strip().strip('"\'')
|
|
|
|
|
name = bare.split("=")[0]
|
|
|
|
|
if name in drop and (bare == name or bare.startswith(name + "=")):
|
|
|
|
|
continue
|
|
|
|
|
out.append(ln)
|
|
|
|
|
return "".join(out)
|
|
|
|
|
|
|
|
|
|
# Every depends array in the file: the top-level one and each sub-package's.
|
|
|
|
|
s = re.sub(r"(?<=depends=\()[^)]*(?=\))", lambda m: prune(m.group(0)), s)
|
|
|
|
|
io.open("PKGBUILD", "w", encoding="utf-8").write(s)
|
|
|
|
|
|
|
|
|
|
# Assert, do not hope. Any dropped name still inside a depends array is a
|
|
|
|
|
# package we would ship unable to install.
|
|
|
|
|
left = []
|
|
|
|
|
for m in re.finditer(r"depends=\(([^)]*)\)", s):
|
|
|
|
|
for ln in m.group(1).splitlines():
|
|
|
|
|
bare = ln.strip().strip('"\'').split("=")[0]
|
|
|
|
|
if bare in drop:
|
|
|
|
|
left.append(bare)
|
|
|
|
|
assert not left, "gcc: dropped names still depended on: %s" % sorted(set(left))
|
|
|
|
|
print("gcc: depends pruned of %d dropped components" % len(drop))
|
|
|
|
|
PY
|
[FIX] gcc: two defects only a chroot could find
Our gcc package was built a dozen times and never once used to compile
anything -- stage 1 compiles with Ubuntu's gcc. The first program it was ever
asked to link was in the stage-2 chroot, and it failed twice.
collect2: fatal error: cannot find 'ld'
/usr/bin/ld was present, executable, on PATH, and ran as the same user. -B,
COMPILER_PATH and three symlinks changed nothing. strace settled it in one
line: it was looking for s390x-linux-gnu-ld, the DEBIAN triplet, and printing
the generic name. gcc's configure had recorded Ubuntu's copy, a file no Arch
system will ever have. --with-ld and --with-as now pin absolute paths, correct
on the host, in the chroot and on the target alike.
/usr/bin/ld: cannot find -lgcc_s
package_gcc() moves libgcc_s{,_asneeded}.so three directories deeper. The
asneeded one is a linker script and survives; libgcc_s.so is a symlink naming
its target relative to /usr/lib, so after the move it points at nothing. The
only libgcc_s.so on the system was dangling, so -lgcc_s could not resolve and
nothing linked at all -- not even int main(void){return 0;}.
Verified: the chroot now compiles and runs a program.
--- FR ---
Notre paquet gcc a été bâti une douzaine de fois sans jamais servir à
compiler : l'étage 1 compile avec le gcc d'Ubuntu. Le premier programme qu'on
lui a demandé de lier l'a été dans le chroot d'étage 2, et il a échoué deux
fois.
collect2: fatal error: cannot find 'ld'
/usr/bin/ld était présent, exécutable, dans le PATH, et répondait pour le même
utilisateur. -B, COMPILER_PATH et trois liens symboliques n'ont rien changé.
strace a tranché en une ligne : il cherchait s390x-linux-gnu-ld, le triplet
DEBIAN, en affichant le nom générique. La configuration de gcc avait
enregistré la copie d'Ubuntu, un fichier qu'aucun système Arch n'aura jamais.
--with-ld et --with-as épinglent désormais des chemins absolus, corrects sur
l'hôte, dans le chroot et sur la cible.
/usr/bin/ld: cannot find -lgcc_s
package_gcc() déplace libgcc_s{,_asneeded}.so trois répertoires plus bas.
Le second est un script ld et survit ; libgcc_s.so est un symlink dont la
cible est relative à /usr/lib, si bien qu'après le déplacement il ne pointe
plus sur rien. Le seul libgcc_s.so du système pendait dans le vide : -lgcc_s
ne pouvait se résoudre et plus rien ne se liait — pas même
int main(void){return 0;}.
Vérifié : le chroot compile et exécute désormais un programme.
Assisted-by: Claude Opus 5
2026-08-19 08:30:49 -04:00
|
|
|
|
|
|
|
|
# --with-ld / --with-as: our gcc looked for a Debian-named linker.
|
|
|
|
|
#
|
|
|
|
|
# Found only by building a chroot from stage 1 and trying to compile in it:
|
|
|
|
|
#
|
|
|
|
|
# collect2: fatal error: cannot find 'ld'
|
|
|
|
|
#
|
|
|
|
|
# THE MESSAGE NAMES THE WRONG FILE. /usr/bin/ld was present and executable,
|
|
|
|
|
# ld --version ran as the same user, and PATH contained /usr/bin. strace
|
|
|
|
|
# settled it in one line:
|
|
|
|
|
#
|
|
|
|
|
# newfstatat("/usr/bin/s390x-linux-gnu-ld") = ENOENT
|
|
|
|
|
#
|
|
|
|
|
# collect2 was not looking for `ld`. It was looking for
|
|
|
|
|
# `s390x-linux-gnu-ld` -- the DEBIAN triplet -- and printing the generic name
|
|
|
|
|
# in its error. gcc -dumpmachine says s390x-ibm-linux-gnu, so the prefix is
|
|
|
|
|
# not the target either; it is what gcc's configure recorded after finding
|
|
|
|
|
# Ubuntu's /usr/bin/s390x-linux-gnu-ld, which that host ships and no Arch
|
|
|
|
|
# system ever will.
|
|
|
|
|
#
|
|
|
|
|
# THE REASON STAGE 1 NEVER NOTICED is that every stage-1 build ran on the
|
|
|
|
|
# host, where that file exists. The defect was in the shipped compiler all
|
|
|
|
|
# along and only a chroot could see it -- the same lesson as the missing
|
|
|
|
|
# dynamic linker, one layer up: sixty-eight successful builds proved nothing
|
|
|
|
|
# about whether the compiler works anywhere else.
|
|
|
|
|
#
|
|
|
|
|
# Absolute paths rather than the canonical triplet, because they are correct
|
|
|
|
|
# in BOTH places: /usr/bin/ld is Ubuntu's during stage 1 and ours in the
|
|
|
|
|
# chroot and on the target. A triplet-prefixed symlink would have papered
|
|
|
|
|
# over it and shipped a gcc that still needs a Debian-named tool.
|
|
|
|
|
python3 - <<'PY'
|
|
|
|
|
import io
|
|
|
|
|
s = io.open("PKGBUILD", encoding="utf-8").read()
|
|
|
|
|
assert "--with-ld=" not in s, "gcc: linker already pinned, hook ran twice"
|
|
|
|
|
# _confflags is an ARRAY, shared by both configure passes -- the compiler and
|
|
|
|
|
# libgccjit -- so one insertion covers both, and no line-continuation
|
|
|
|
|
# backslash belongs on the new entries.
|
|
|
|
|
anchor = " --with-linker-hash-style=gnu\n"
|
|
|
|
|
n = s.count(anchor)
|
|
|
|
|
assert n == 1, "gcc: expected one --with-linker-hash-style in _confflags, found %d" % n
|
|
|
|
|
s = s.replace(anchor, anchor + " --with-ld=/usr/bin/ld\n --with-as=/usr/bin/as\n", 1)
|
|
|
|
|
io.open("PKGBUILD", "w", encoding="utf-8").write(s)
|
|
|
|
|
print("gcc: ld and as pinned to absolute paths")
|
|
|
|
|
PY
|
|
|
|
|
grep -q -- '--with-ld=/usr/bin/ld' PKGBUILD || {
|
|
|
|
|
echo "gcc: --with-ld not inserted" >&2; exit 1; }
|
|
|
|
|
|
|
|
|
|
# libgcc_s.so: the PKGBUILD moves a RELATIVE symlink into a deeper directory.
|
|
|
|
|
#
|
|
|
|
|
# /usr/bin/ld: cannot find -lgcc_s: No such file or directory
|
|
|
|
|
#
|
|
|
|
|
# package_gcc() does, at the end:
|
|
|
|
|
#
|
|
|
|
|
# mv -v usr/lib/libgcc_s{,_asneeded}.so $_libdir/
|
|
|
|
|
#
|
|
|
|
|
# where $_libdir is /usr/lib/gcc/<triplet>/16. The two files are not alike.
|
|
|
|
|
# libgcc_s_asneeded.so is a linker SCRIPT -- `INPUT ( AS_NEEDED ( -lgcc_s ) )`
|
|
|
|
|
# -- so it survives being moved anywhere. libgcc_s.so is a SYMLINK whose
|
|
|
|
|
# target is the bare name `libgcc_s.so.1`, i.e. the same directory. That was
|
|
|
|
|
# true in /usr/lib, where libgcc_s.so.1 lives; three directories deeper it
|
|
|
|
|
# points at nothing.
|
|
|
|
|
#
|
|
|
|
|
# So -lgcc_s cannot resolve: the only libgcc_s.so on the system is a dangling
|
|
|
|
|
# link, and the asneeded script that ld reads instead asks for -lgcc_s again.
|
|
|
|
|
# Nothing links, including the trivial `int main(void){return 0;}`.
|
|
|
|
|
#
|
|
|
|
|
# WHY NOTHING CAUGHT THIS EARLIER, and it is the same reason as the linker
|
|
|
|
|
# lookup above: stage 1 compiles with UBUNTU's gcc. Our gcc package was built
|
|
|
|
|
# a dozen times and never once used to compile anything. The first program it
|
|
|
|
|
# was ever asked to link was in the stage-2 chroot.
|
|
|
|
|
#
|
|
|
|
|
# The link is repointed rather than the mv removed, because $_libdir is where
|
|
|
|
|
# gcc's own search path expects it -- that part of the PKGBUILD is right.
|
|
|
|
|
# Three levels up from /usr/lib/gcc/<triplet>/16 is /usr/lib.
|
|
|
|
|
python3 - <<'PY'
|
|
|
|
|
import io
|
|
|
|
|
s = io.open("PKGBUILD", encoding="utf-8").read()
|
|
|
|
|
old = ' mv -v usr/lib/libgcc_s{,_asneeded}.so $_libdir/\n'
|
|
|
|
|
assert s.count(old) == 1, "gcc: libgcc_s move not in the expected form"
|
|
|
|
|
fix = old + (
|
|
|
|
|
' # The moved symlink named its target relative to /usr/lib; from\n'
|
|
|
|
|
' # $_libdir that resolves to nothing. Repoint it, or -lgcc_s cannot\n'
|
|
|
|
|
' # be satisfied and the compiler links nothing at all.\n'
|
|
|
|
|
' ln -sfv ../../../libgcc_s.so.1 $_libdir/libgcc_s.so\n')
|
|
|
|
|
s = s.replace(old, fix, 1)
|
|
|
|
|
io.open("PKGBUILD", "w", encoding="utf-8").write(s)
|
|
|
|
|
PY
|
|
|
|
|
grep -qF 'ln -sfv ../../../libgcc_s.so.1' PKGBUILD || {
|
|
|
|
|
echo "gcc: libgcc_s.so link not repointed" >&2; exit 1; }
|
|
|
|
|
echo "gcc: libgcc_s.so repointed to ../../../libgcc_s.so.1"
|
[FIX] s390x: say which machine this port targets
zlib stopped on '__builtin_s390_vec_unpackl' requires '-mvx', after its own
configure had detected vector support and defined -DHAVE_S390X_VX. Both halves
were right, so it was worth measuring rather than patching:
host gcc (Ubuntu) --with-arch=z13 --with-tune=z16 default -march=arch11
our gcc nothing default -march=arch5
arch5 is z900, from 2000. Arch's PKGBUILD names no s390x baseline because Arch
has no s390x, so ours fell back to the oldest machine imaginable while zlib went
on detecting a CPU the compiler had been told to forget. Every distribution
picks one of these; this port had never said which, and silence chose 2000.
z13 is what Ubuntu s390x already requires, so nothing that runs today stops.
Set in two places: makepkg.conf, how this distribution is compiled, and gcc's
--with-arch, what the compiler we ship assumes with no flags at all.
--- FR ---
zlib s'est arrêté sur '__builtin_s390_vec_unpackl' requires '-mvx', après que
son propre configure avait détecté le support vectoriel et défini
-DHAVE_S390X_VX. Les deux moitiés avaient raison : il fallait mesurer, pas
rustiner.
gcc de l'hôte --with-arch=z13 --with-tune=z16 défaut -march=arch11
notre gcc rien défaut -march=arch5
arch5, c'est z900, de l'an 2000. Le PKGBUILD d'Arch ne nomme aucune base s390x
puisque Arch n'a pas de s390x : le nôtre retombait sur la machine la plus
ancienne imaginable pendant que zlib détectait un processeur qu'on avait dit au
compilateur d'oublier. Toute distribution en choisit une ; ce portage ne l'avait
jamais dit, et le silence a choisi 2000.
z13 est ce qu'Ubuntu s390x exige déjà : rien qui tourne aujourd'hui ne cesse de
tourner. Posé aux deux endroits : makepkg.conf, comment cette distribution est
compilée, et le --with-arch de gcc, ce que suppose le compilateur qu'on livre.
Assisted-by: Claude Opus 5
2026-08-21 00:23:26 -04:00
|
|
|
|
|
|
|
|
# --- the baseline CPU of the compiler we SHIP ---------------------------------
|
|
|
|
|
#
|
|
|
|
|
# Arch's PKGBUILD names no s390x baseline, because Arch has no s390x. GCC's own
|
|
|
|
|
# fallback for this target is arch5 -- z900, from the year 2000 -- and that is
|
|
|
|
|
# what our gcc defaulted to while the host's Ubuntu gcc is configured
|
|
|
|
|
# --with-arch=z13 --with-tune=z16. The consequence was not a warning:
|
|
|
|
|
#
|
|
|
|
|
# contrib/crc32vx/crc32_vx.c:205:10: error:
|
|
|
|
|
# '__builtin_s390_vec_unpackl' requires '-mvx'
|
|
|
|
|
#
|
|
|
|
|
# zlib's configure had detected vector support and defined -DHAVE_S390X_VX,
|
|
|
|
|
# then compiled with a compiler told to assume a machine that has none.
|
|
|
|
|
#
|
|
|
|
|
# build-stage2.sh sets the same pair in the chroot's makepkg.conf, which governs
|
|
|
|
|
# how this distribution is COMPILED. This governs what the compiler we HAND OVER
|
|
|
|
|
# assumes when someone builds on the target with no flags at all. Doing only the
|
|
|
|
|
# first leaves a gcc that silently goes back to 2000.
|
|
|
|
|
#
|
|
|
|
|
# z13 because that is what the host distribution already requires: adopting it
|
|
|
|
|
# cannot stop anything from running that runs today.
|
|
|
|
|
python3 - <<'ZZPY'
|
|
|
|
|
import io, re
|
|
|
|
|
lines = io.open("PKGBUILD", encoding="utf-8").read().split("\n")
|
|
|
|
|
hit = [i for i, l in enumerate(lines) if "--enable-languages=" in l and "jit" not in l]
|
|
|
|
|
assert len(hit) == 1, "gcc: expected one main --enable-languages line, got %d" % len(hit)
|
|
|
|
|
i = hit[0]
|
|
|
|
|
indent = re.match(r"^[ \t]*", lines[i]).group(0)
|
|
|
|
|
assert lines[i].rstrip().endswith("\\"), "gcc: --enable-languages does not continue"
|
|
|
|
|
lines.insert(i + 1, indent + "--with-arch=z13 --with-tune=z16 \\")
|
|
|
|
|
io.open("PKGBUILD", "w", encoding="utf-8").write("\n".join(lines))
|
|
|
|
|
ZZPY
|
|
|
|
|
grep -q -- '--with-arch=z13' PKGBUILD || { echo "gcc: baseline not set" >&2; exit 1; }
|
|
|
|
|
# On the configure line, not merely in the file.
|
|
|
|
|
#
|
|
|
|
|
# The first version of this check anchored on --enable-languages=ada and failed
|
|
|
|
|
# on a PKGBUILD that was correctly patched: a section ABOVE has already
|
|
|
|
|
# rewritten the language list, so `ada` is gone by the time this runs. The
|
|
|
|
|
# guard was testing its own stale assumption about the file rather than the
|
|
|
|
|
# edit -- the fourth time in this port that a check has verified something
|
|
|
|
|
# adjacent to what it meant. Anchor on what the python actually matched.
|
|
|
|
|
grep -A1 -E -- '--enable-languages=' PKGBUILD | grep -q -- '--with-arch=z13' || {
|
|
|
|
|
echo "gcc: --with-arch is in the file but not on the configure line" >&2; exit 1; }
|
|
|
|
|
echo "gcc: baseline z13, tune z16"
|
[FIX] binutils' extra targets were x86_64's, and gcc only wanted man pages
gold failed to link with
s390.cc: undefined reference to `void gold::gold_error_at_location<32, true>'
Its s390 target file compiles code for both s390 and s390x and references
<32, true> instantiations, which exist only when a 32-bit s390 target is
configured. The PKGBUILD asks for --enable-targets=x86_64-pep,bpf-unknown-none.
x86_64-pep is the PE+ target for x86_64: it means nothing here, and on x86_64 it
is what happens to bring in the 32-bit instantiations gold's target files want.
So this was never a gold bug -- it is the -march=x86-64 story one layer further
in. s390-linux-gnu is the honest translation of that line.
gcc now compiles, Fortran front end included, and stopped in package_gcc() on
libstdc++'s doxygen man pages -- two places, build and install, the eighth time
this port has met that shape.
--- FR ---
gold ne se liait pas :
s390.cc: undefined reference to `void gold::gold_error_at_location<32, true>'
Son fichier de cible s390 compile pour s390 et s390x et référence des
instanciations <32, true>, qui n'existent que si une cible s390 32 bits est
configurée. Le PKGBUILD demande --enable-targets=x86_64-pep,bpf-unknown-none.
x86_64-pep est la cible PE+ d'x86_64 : elle ne veut rien dire ici, et sur x86_64
c'est elle qui amène par hasard les instanciations 32 bits que gold réclame. Ce
n'était donc pas un défaut de gold — c'est l'histoire du -march=x86-64 une couche
plus loin. s390-linux-gnu est la traduction honnête de cette ligne.
gcc compile désormais, front-end Fortran compris, et s'arrêtait dans
package_gcc() sur les pages de manuel doxygen de libstdc++ — deux endroits,
construction et installation, huitième fois que ce portage rencontre cette forme.
Assisted-by: Claude Opus 5
2026-08-22 21:52:39 -04:00
|
|
|
|
|
|
|
|
# --- no libstdc++ man pages ----------------------------------------------------
|
|
|
|
|
#
|
|
|
|
|
# make: *** [Makefile:890: doc-install-man] Error 1
|
|
|
|
|
# ==> ERROR: A failure occurred in package_gcc()
|
|
|
|
|
#
|
|
|
|
|
# gcc now COMPILES here -- what remained was libstdc++'s API documentation, built
|
|
|
|
|
# with doxygen. TWO PLACES: doc-man-doxygen in build() and doc-install-man in
|
|
|
|
|
# package(). Removing only the first fails on the second, which is the shape this
|
|
|
|
|
# port has now hit eight times.
|
|
|
|
|
#
|
|
|
|
|
# Worth noting how close this was to the end: the whole of gcc, including the
|
|
|
|
|
# Fortran front end that had failed for six passes, built successfully and then
|
|
|
|
|
# stopped on man pages.
|
|
|
|
|
python3 - <<'ZZPY'
|
|
|
|
|
import io, re
|
|
|
|
|
lines = io.open("PKGBUILD", encoding="utf-8").read().split("\n")
|
|
|
|
|
hit = [i for i, l in enumerate(lines)
|
|
|
|
|
if re.search(r"doc-man-doxygen|doc-install-man", l)]
|
|
|
|
|
assert len(hit) == 2, "gcc: expected two libstdc++ doc lines, got %d" % len(hit)
|
|
|
|
|
for i in reversed(hit):
|
|
|
|
|
ind = re.match(r"^[ \t]*", lines[i]).group(0)
|
|
|
|
|
lines[i] = ind + ": # libstdc++ man pages need doxygen, which this port lacks."
|
|
|
|
|
io.open("PKGBUILD", "w", encoding="utf-8").write("\n".join(lines))
|
|
|
|
|
ZZPY
|
|
|
|
|
grep -qE "doc-man-doxygen|doc-install-man" PKGBUILD && {
|
|
|
|
|
echo "gcc: a libstdc++ doc target survived" >&2; exit 1; }
|
|
|
|
|
echo "gcc: libstdc++ man pages dropped"
|