Linux AppImage v2.0.5: link FAILED, 20 undefined symbols (f_811f3a80 ...), v2.0.4 builds fine #890

Closed

opened 2026-11-09 00:24:41 +00:00 by GuiFlam · 2 comments

GuiFlam commented

2026-11-09 00:24:41 +00:00

(Migrated from github.com)

Builder version

v2.0.5 (Linux AppImage Hookshot-v2.0.5-x86_64.AppImage)

How you built

Linux AppImage, --cli. Tried both ways: --update <game folder> (kept from a v2.0.4 build) and a full --nup build into the same folder.

Game files given to it

A .nup (two titles: base v65536 + update v131072). --check reports "This is the version Hookshot supports (build e0f3ccfa)". v2.0.4 built from the same .nup on the same machine without problems.

The error

The compile step finishes, then the link fails with the same 20 undefined symbols, every time:

243 files, 4 jobs, -O1 -DA64_POLLING -DA64_WRITE_TRACK
compiled in 1087s, 0 failed
link FAILED (1s), 20 undefined symbols
ld.lld: error: undefined symbol: f_811f3a80
ld.lld: error: undefined symbol: f_811fe7d0
ld.lld: error: undefined symbol: f_81231c00
... (20 in total, all of the form f_81xxxxxx; the list is below)
@@error build.py stopped (exit status 1): ld.lld: error: undefined symbol: f_81e100b4

All 20 symbols:

f_811f3a80
f_811fe7d0
f_81231c00
f_812bcd10
f_812bcd60
f_812bcec0
f_812c3470
f_812c3480
f_812c34e0
f_812c3500
f_818429d0
f_81865380
f_81865f00
f_81b44ebc
f_81b56000
f_81cdd400
f_81cde780
f_81cdefa0
f_81ce1b80
f_81ce1c00

What I checked

object keys: ... lifted code acd0d8dd37 (65 files) for v2.0.5; v2.0.4 had lifted code 0d1917efe9 (80 files). Same game headers and flags keys.
The first attempts took every object from the cache ("compiled in 0s"). I then moved both object caches aside (hookshot-work/objcache and hookshot-work/sa/build/obj) and did a clean full build: all 243 files compiled, 0 failed, and the link fails with the same 20 symbols. So it is not a stale cache.
In the generated C, the 20 functions are declared and called (for example f_811f3a80 in code_000.c, code_008.c and a64_table.c) and listed in functions.txt, but I did not find a definition for them in the compiled code_NNN.c / code_hot_N.c files. I have not worked out why the lift leaves them out.
The game folder was not touched: the build stops before it replaces anything, so the v2.0.4 install still runs.

Environment

Fedora 43 (KDE Plasma, Wayland), kernel 7.2, NVIDIA RTX 3050 Ti Laptop 4 GB (driver 580), Intel i9-12900HK, 15 GB RAM. 4 compile jobs.

Happy to attach the full build logs or test a fix.

### Builder version v2.0.5 (Linux AppImage `Hookshot-v2.0.5-x86_64.AppImage`) ### How you built Linux AppImage, `--cli`. Tried both ways: `--update <game folder>` (kept from a v2.0.4 build) and a full `--nup` build into the same folder. ### Game files given to it A .nup (two titles: base v65536 + update v131072). `--check` reports "This is the version Hookshot supports (build e0f3ccfa)". v2.0.4 built from the same .nup on the same machine without problems. ### The error The compile step finishes, then the link fails with the same 20 undefined symbols, every time: ```text 243 files, 4 jobs, -O1 -DA64_POLLING -DA64_WRITE_TRACK compiled in 1087s, 0 failed link FAILED (1s), 20 undefined symbols ld.lld: error: undefined symbol: f_811f3a80 ld.lld: error: undefined symbol: f_811fe7d0 ld.lld: error: undefined symbol: f_81231c00 ... (20 in total, all of the form f_81xxxxxx; the list is below) @@error build.py stopped (exit status 1): ld.lld: error: undefined symbol: f_81e100b4 ``` All 20 symbols: ```text f_811f3a80 f_811fe7d0 f_81231c00 f_812bcd10 f_812bcd60 f_812bcec0 f_812c3470 f_812c3480 f_812c34e0 f_812c3500 f_818429d0 f_81865380 f_81865f00 f_81b44ebc f_81b56000 f_81cdd400 f_81cde780 f_81cdefa0 f_81ce1b80 f_81ce1c00 ``` ### What I checked - `object keys: ... lifted code acd0d8dd37 (65 files)` for v2.0.5; v2.0.4 had `lifted code 0d1917efe9 (80 files)`. Same game headers and flags keys. - The first attempts took every object from the cache ("compiled in 0s"). I then moved both object caches aside (`hookshot-work/objcache` and `hookshot-work/sa/build/obj`) and did a clean full build: all 243 files compiled, 0 failed, and the link fails with the same 20 symbols. So it is not a stale cache. - In the generated C, the 20 functions are declared and called (for example `f_811f3a80` in `code_000.c`, `code_008.c` and `a64_table.c`) and listed in `functions.txt`, but I did not find a definition for them in the compiled `code_NNN.c` / `code_hot_N.c` files. I have not worked out why the lift leaves them out. - The game folder was not touched: the build stops before it replaces anything, so the v2.0.4 install still runs. ### Environment Fedora 43 (KDE Plasma, Wayland), kernel 7.2, NVIDIA RTX 3050 Ti Laptop 4 GB (driver 580), Intel i9-12900HK, 15 GB RAM. 4 compile jobs. Happy to attach the full build logs or test a fix.

amaralthalesalves commented

2026-11-09 01:27:04 +00:00

(Migrated from github.com)

Thanks for the detailed report. Your 65 code files is 57 chunks plus the 8 hot pieces with none of the 15 code_NNN_k.c parts, and the missing functions sit in the tails of the big chunks, which is what those parts hold. On top of that, the lift cache (sa/gen/.lift_key) kept vouching for that C, so a clean compile reused it too.

Workaround: delete ~/.cache/hookshot-builder/sa/gen/.lift_key (or the whole sa/gen folder), then build once with no other Hookshot build running. Was a second build running at the same time when it first failed (another builder window, or the game's update offer)? The lift part of that first v2.0.5 log would show it: a normal lift prints chunks: code_0NN.c (... MB) in N parts lines.

#918 stops the build from reusing a lift whose functions aren't all defined, and allows one build at a time on a work folder.

Thanks for the detailed report. Your 65 code files is 57 chunks plus the 8 hot pieces with none of the 15 `code_NNN_k.c` parts, and the missing functions sit in the tails of the big chunks, which is what those parts hold. On top of that, the lift cache (`sa/gen/.lift_key`) kept vouching for that C, so a clean compile reused it too. Workaround: delete `~/.cache/hookshot-builder/sa/gen/.lift_key` (or the whole `sa/gen` folder), then build once with no other Hookshot build running. Was a second build running at the same time when it first failed (another builder window, or the game's update offer)? The lift part of that first v2.0.5 log would show it: a normal lift prints `chunks: code_0NN.c (... MB) in N parts` lines. #918 stops the build from reusing a lift whose functions aren't all defined, and allows one build at a time on a work folder.

NotRexed commented

2026-11-09 06:00:31 +00:00

(Migrated from github.com)

Tracked in #1000, follow there. That issue collects every report of Linux / Steam Deck GPU hangs, crashes, low fps and build failures, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

Commenting is not possible because the repository is archived.