Commit graph

3 commits

Author SHA1 Message Date
a42e43bcf1 [FIX] binutils: no PGO+LTO build, so gold links
Built at stage 1, failed at stage 2, in gold:

  <artificial>:(.text+0xc44e): undefined reference to
    `void gold::gold_error_at_location<32, true>(...)'

`<artificial>` and the .ltrans object names are LTO's, and it does not come from
makepkg -- the chroot carries !lto with an empty LTOFLAGS. It comes from the
PKGBUILD: --enable-pgo-build=lto. gold's explicitly-instantiated templates do
not survive it here. Stage 1 got away with it because the host's GCC did the
work; stage 2 uses ours, at -O2 -march=z13 where stage 1 passed no flags.

PGO and LTO are build-time optimisations: what changes is how long binutils
takes to compile and how fast the linker runs, not what it can do. The
alternatives were removing gold, a linker Arch ships, or debugging LTO template
instantiation in a linker upstream has deprecated.

The first attempt at this hook looked for --with-build-config=bootstrap-lto,
which is in gcc's PKGBUILD, not binutils'. Its own assertion caught it.

--- FR ---

Bâti à l'étage 1, échoué à l'étage 2, dans gold :

  <artificial>:(.text+0xc44e): undefined reference to
    `void gold::gold_error_at_location<32, true>(...)'

`<artificial>` et les noms d'objets .ltrans sont ceux du LTO, et il ne vient pas
de makepkg — le chroot porte !lto avec un LTOFLAGS vide. Il vient du PKGBUILD :
--enable-pgo-build=lto. Les gabarits explicitement instanciés de gold n'y
survivent pas. L'étage 1 s'en tirait car le GCC de l'hôte faisait le travail ;
l'étage 2 utilise le nôtre, à -O2 -march=z13 là où l'étage 1 ne passait rien.

PGO et LTO sont des optimisations de construction : ce qui change, c'est la durée
de compilation et la vitesse du lieur, pas ce qu'il sait faire. Les options
étaient de retirer gold, un lieur qu'Arch livre, ou de déboguer une instanciation
de gabarit sous LTO dans un lieur abandonné en amont.

La première version de ce hook cherchait --with-build-config=bootstrap-lto, qui
est dans le PKGBUILD de gcc, pas de binutils. Sa propre assertion l'a arrêtée.

Assisted-by: Claude Opus 5
2026-08-21 04:16:20 -04:00
f380f3fd66 [FIX] one stray .a file broke every pkg-config lookup
libxslt reported

  configure: error: Package requirements (python-3.14) were not met:
  Package 'python-3.14' not found

with python 3.14.7 installed and /usr/lib/pkgconfig/python-3.14.pc present. The
chain, none of whose links resembles the others:

  binutils installs libiberty.a into /usr/lib64, because s390x's default
  MULTILIB_OSDIRNAME is lib64, creating that path as a REAL directory. meson
  chooses its default libdir by inspecting the system, and 64-bit plus a real
  /usr/lib64 means lib64 -- a symlink does not count, which is why Arch never
  sees this and arch-meson passes no --libdir at all. pkgconf is a meson
  package, so it installed there and COMPILED IN /usr/lib64/pkgconfig as its
  search path. Every .pc in the distribution is in /usr/lib/pkgconfig.

Fixed at all three levels: binutils pinned to --libdir=/usr/lib, the chroot's
arch-meson wrapper pins --libdir lib as a backstop, and the ARTEFACT check --
which said "no Debian multiarch libdir anywhere", truthfully and uselessly --
now also counts paths under usr/lib64.

--- FR ---

libxslt annonçait

  configure: error: Package requirements (python-3.14) were not met:
  Package 'python-3.14' not found

avec python 3.14.7 installé et /usr/lib/pkgconfig/python-3.14.pc bien présent.
La chaîne, dont aucun maillon ne ressemble aux autres :

  binutils dépose libiberty.a dans /usr/lib64, le MULTILIB_OSDIRNAME par défaut
  de s390x, et crée donc ce chemin comme VRAI répertoire. meson choisit son
  libdir par défaut en inspectant le système : 64 bits plus un vrai /usr/lib64
  donne lib64 — un lien ne compte pas, d'où le fait qu'Arch ne voit jamais cela
  et qu'arch-meson ne passe aucun --libdir. pkgconf étant un paquet meson, il
  s'y est installé et a COMPILÉ /usr/lib64/pkgconfig comme chemin de recherche.
  Or tous les .pc de la distribution sont dans /usr/lib/pkgconfig.

Corrigé aux trois niveaux : binutils épinglé à --libdir=/usr/lib, l'enveloppe
arch-meson du chroot épingle --libdir lib en filet, et le test ARTEFACT — qui
répondait « aucun libdir multiarch Debian », véridiquement et inutilement —
compte désormais aussi les chemins sous usr/lib64.

Assisted-by: Claude Opus 5
2026-08-21 00:47:09 -04:00
f87502622a [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