[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",
|
|
|
|
|
# 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
|
|
|
|
|
|
|
|
|
|
# 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.
|
|
|
|
|
for _lang in gcc-ada gcc-d gcc-go gcc-m2 gcc-rust gcc-gcobol \
|
|
|
|
|
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
|
|
|
|
|
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"
|