archlinux-s390x/patches/pkgbuild/gcc.sh

80 lines
3.4 KiB
Bash
Raw Normal View History

[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
[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
sed -i '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
# 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] 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"