Repository navigation
Avoid building a static library for CPU target code #23
Description
Offloading with target on the CPU requires creating a self-contained shared library for the CPU code. Numba lowering inserts calls to NRT or helperlib functions, which are not exported through Numba-compiled shared libraries. Additionally, we need to init the NRT memory system (NRT_MemSys_Init) to make it usable from the standalone CPU target code.
Currently, we build a static library by pulling sources from the Numba installation, insert a constructor for initialization (the memory system), and link that static library with the shared library CPU target code. Packaging a wheel pulls those sources from the specific Numba version installed at build time. This works across Numba versions because those APIs and their implementations are fairly stable, but it's not ideal.
I can think of the following alternatives:
- PyOMP builds the static library at JIT time instead of packaging it, pulling sources from the Numba installation. PyOMP can cache that library to avoid rebuilding for another CPU target region
- Numba provides a static library
(or LLVM bitcode library)1 that PyOMP links at JIT time
Footnotes
-
bitcode library will require the user to have python development headers which is not ideal ↩
Activity
ggeorgakoudis commentedon Sep 10, 2025
PR #21 partially fixes this by going with
approach 1: building the static library at runtimecreating trampolines to the absolute symbol addresses loaded as python extension modules by numba, roughly similar to how numba adds those symbols to the execution engineI will leave the issue open because I think the ideal solution is approach 2, but requires upstream Numba changes.