Summary
The top-level Makefile links libfastfields.so without actually declaring a dependency on the cpu submake (libfastfields-cpu.so) finishing first. Under make -j, the link step can run before the CPU sub-library is built, failing with ld: cannot find -lfastfields-cpu.
Evidence
Confirmed in real CI, not hypothetical: caught while adding a build-native CI job in fastfields/.github#8 that ran make -j for the first time in that context — run 30765648736 failed with exactly this error. Dropping -j (matching what fastfields-dlpack/setup.py's existing from-source build path has always done) fixed it immediately — run 30766596649 went green.
Impact
Non-blocking today only because nothing in the current release pipeline passes -j to make (worked around in .github#8 by just not using it). But it's a real correctness bug in the Makefile's dependency graph, and it's the reason build-native's CI job builds single-threaded (~27min) instead of parallel — see the "Honest timing comparison" section of fastfields/.github#8's description for the follow-up this blocks.
Fix
Add an explicit make dependency so the libfastfields.so link rule depends on the cpu/libcpu submake target completing, not just on ordering that happens to work out under -j1. (cuda's submake likely has the analogous issue once CUDA -j builds are exercised in CI — worth checking at the same time.)
Workstream: claude-jitfields-to-fastfields
Summary
The top-level Makefile links
libfastfields.sowithout actually declaring a dependency on thecpusubmake (libfastfields-cpu.so) finishing first. Undermake -j, the link step can run before the CPU sub-library is built, failing withld: cannot find -lfastfields-cpu.Evidence
Confirmed in real CI, not hypothetical: caught while adding a
build-nativeCI job infastfields/.github#8that ranmake -jfor the first time in that context — run 30765648736 failed with exactly this error. Dropping-j(matching whatfastfields-dlpack/setup.py's existing from-source build path has always done) fixed it immediately — run 30766596649 went green.Impact
Non-blocking today only because nothing in the current release pipeline passes
-jtomake(worked around in.github#8by just not using it). But it's a real correctness bug in the Makefile's dependency graph, and it's the reasonbuild-native's CI job builds single-threaded (~27min) instead of parallel — see the "Honest timing comparison" section offastfields/.github#8's description for the follow-up this blocks.Fix
Add an explicit make dependency so the
libfastfields.solink rule depends on thecpu/libcpusubmake target completing, not just on ordering that happens to work out under-j1. (cuda's submake likely has the analogous issue once CUDA-jbuilds are exercised in CI — worth checking at the same time.)Workstream: claude-jitfields-to-fastfields