29091, "dlongnecke-cray", "Support a PIC Chapel runtime without requiring generated code to be PIC", "2026-07-08T17:26:05Z"
Background
Chapel's ability to dynamically load another Chapel library currently relies on the new(ish) compilation flag --no-builtin-runtime.
When thrown, this flag causes the Chapel program being built to be linked against libchpl.so instead of the static archive libchpl-static.a. This means that a copy of the runtime's code is not actually built into the Chapel program (thus the name "no builtin runtime").
Currently, libchpl.so can only be built when the Chapel environment configuration is set to CHPL_LIB_PIC=pic. This is because a .so/.dylib dynamic library requires position-independent code (PIC) in order to be loaded at all.
Because of this requirement, currently --no-builtin-runtime requires the user's compilation session to be CHPL_LIB_PIC=pic.
Problem
The problem is that by always requiring CHPL_LIB_PIC=pic, not only will the runtime and all third-party dependencies be built as PIC, but all generated Chapel code will be built as PIC as well.
This seems like overkill when all we really need is for the Chapel runtime (and transitively, all the third-party dependencies it requires) to be built as CHPL_LIB_PIC. We don't really need to care if the compiler-generated code has relocations - this is handled by the compilation mode (e.g., --library --dynamic).
In general, we would like to avoid introducing PIC unless the user requires it due to performance reasons.
Feature Request
It would be nice if the Chapel compiler could detect if an existing Chapel configuration exists that is almost identical to the user-requested installation, except with the difference of CHPL_LIB_PIC=pic.
Then, the compiler could link against the libchpl.so in the sibling PIC configuration without having to require the user to set CHPL_LIB_PIC=pic themselves, or to throw --lib-pic=pic.