blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a3d94d4d5e532e25353a204906121b42ab04abc6
IdeA/.ideai/memory/appimage-build-no-strip-relr-dyn-fix.md
Blomios 98fb05447d chore(ideai): état runtime — tickets, mémoire, tâches de fond 
État d'exécution accumulé (tickets créés/mis à jour hors #43, notes de
mémoire, tâche de fond) capturé au moment du commit de la feature.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-22 07:37:19 +02:00

3.8 KiB
Raw Blame History

name, description, metadata
name description metadata
appimage-build-no-strip-relr-dyn-fix memory note appimage-build-no-strip-relr-dyn-fix
type
project

Build AppImage — échec linuxdeploy .relr.dyn, correctif NO_STRIP=true

Symptôme

tauri build --bundles appimage : la compilation release réussit (binaire à target/release/app-tauri), puis le bundling échoue :

[gtk/stdout] ERROR: Strip call failed: .../usr/bin/strip: .../libgobject-2.0.so...:
  unknown type [0x13] section `.relr.dyn'
ERROR: Failed to run plugin: gtk (exit code: 1)
failed to bundle project `failed to run .../.cache/tauri/linuxdeploy-x86_64.AppImage`

→ aucune AppImage produite, exit code 1. Le tail du log ne montrait au début que « failed to run linuxdeploy » sans détail ⇒ facile à prendre pour un blocage/bash de fond.

Cause racine (environnement, PAS le code IdeA)

Le strip (binutils) embarqué dans le vieux linuxdeploy-x86_64.AppImage ne comprend pas la section ELF moderne .relr.dyn (relocations DT_RELR, unknown type [0x13]) présente dans les libs système GTK/glibc de CachyOS/Arch (rolling). Le plugin gtk de linuxdeploy strip ces libs → échec → tout le bundling casse.

Correctif VALIDÉ (2026-07-02, toujours valable 2026-07-17)

Lancer le build avec NO_STRIP=true (le binaire release est déjà strippé par cargo) :

cd crates/app-tauri
NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage

Résultat : Finished 1 bundle at target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage.

Séquence de build — MISE À JOUR après #74 (2026-07-17)

Attention : l'ancienne version de cette note disait « pas de beforeBuildCommand dans tauri.conf.json » et imposait un npm run build manuel préalable. C'est FAUX depuis #74.

crates/app-tauri/tauri.conf.json a maintenant :

  • build.beforeBuildCommand: "npm --prefix ../frontend run build:bundle"
  • bundle.resources: { "../../frontend/dist-web": "web" }

et frontend/package.json définit :

"build:bundle": "npm run typecheck && vite build --outDir dist --emptyOutDir && vite build --mode web --outDir dist-web --emptyOutDir"

Donc une seule commande suffit, le frontend est construit automatiquement (les DEUX bundles) :

cd crates/app-tauri
NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage

build:bundle produit deux bundles distincts, et c'est le cœur du fix #74 :

  • frontend/dist → bundle desktop, transport tauri (= build.frontendDist).
  • frontend/dist-web → bundle web, transport http (= packagé en ressource web/).

Un seul dist ne peut pas servir les deux : le transport est figé au build par Vite (resolveTransport() lit import.meta.env.VITE_TRANSPORT, constant-folded). C'est ce qui causait __TAURI_INTERNALS__ is undefined dans le navigateur (#74).

Garde-fou : npm run test:bundle-transport vérifie que dist = tauri et dist-web = http. Le lancer après un build si un doute subsiste sur ce qui est servi au navigateur.

Implication produit

C'est très probablement la vraie cause des « builds AppImage qui ne produisent rien / attente sans résultat » signalés par l'utilisateur. À intégrer idéalement dans le flux de build d'IdeA (passer NO_STRIP quand on cible AppImage sur Arch, ou vendoriser un linuxdeploy récent).

Lien : mcp-bridge-and-delegation-runtime-notes (le binaire qui tourne = AppImage, pas les sources — rebuild obligatoire pour tester un changement backend live).