Force PIE on bootgen with explicit compiler/linker flags, not just the CMake property

[jgmelber]

Summary

Follow-up to #3327, which set POSITION_INDEPENDENT_CODE ON on the bootgen/bootgen-lib CMake targets to keep bootgen's ELF layout PIE regardless of what the linked MLIR/LLVM package sets globally. That's needed because auditwheel repair's patchelf-based RPATH rewrite (required to point at vendored/renamed OpenSSL libs) corrupts a non-PIE bootgen: the binary SIGSEGVs (SEGV_ACCERR) jumping into its own non-executable DYNAMIC segment before main() runs, breaking PDI/xclbin generation on real Ryzen AI hardware -- this is what's still failing in #3323.

#3327's fix doesn't actually work. The wheel built from that exact commit (27433d63, AIE_PROJECT_COMMIT in the #3323 build) still ships a non-PIE bootgen:

$ readelf -h mlir_aie/bin/bootgen | grep Type
  Type:                              EXEC (Executable file)
$ strace -f ./mlir_aie/bin/bootgen -help
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x4020f0} ---

(0x4020f0 falls inside that binary's DYNAMIC segment, 0x401fc8-0x4021f8 -- exact same failure mode as before, reproduced by downloading the actual rocm-wheel-ryzenai-validation artifact from the #3323 CI run and running it directly, no hardware needed.)

Root cause of why the property doesn't work: this project never calls include(CheckPIESupported) / check_pie_supported(), which CMake's CMP0083 machinery needs in order to translate the POSITION_INDEPENDENT_CODE target property into actual -fPIE/-pie compiler/linker flags for an executable target. Without that, the property is a no-op here. Compounding it: manylinux_2_28's gcc-toolset-14 (used to build release wheels) doesn't default to PIE the way a distro's system GCC does, so there's no free fallback either.

Fix: pass -fPIC (on bootgen-lib) and -fPIE/-pie (on bootgen) as explicit target_compile_options/target_link_options, placed last so they win via ordinary compiler "last flag wins" semantics over any -fno-pie/-fno-PIC inherited from the linked MLIR/LLVM package's own build configuration -- independent of the property/policy machinery.

Verified locally: built bootgen under a forced -fno-pie -fno-PIC -no-pie global configuration (reproducing the manylinux/ROCm environment). Confirmed the old (#3327) property-only approach still yields a non-PIE EXEC binary under those conditions, while this change reliably produces a true PIE (ET_DYN) bootgen that runs correctly.

Test plan

• CI passes (should be a no-op for every other target)
• Re-run [TEST] ROCm mlir_aie wheel on Ryzen AI self-hosted runners #3323's wheel build + hardware test with this fix included; confirm readelf -h on the shipped bootgen shows DYN, and programming_examples pass

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR hardens bootgen’s PIE/PIC behavior by adding explicit compiler/linker flags in tools/bootgen so the resulting wheel reliably ships a PIE bootgen binary even when global LLVM/MLIR-derived flags would otherwise disable PIE/PIC.

Changes:

• Add explicit -fPIC for bootgen-lib on GNU/Clang toolchains to ensure PIC objects regardless of CMake PIE-property behavior.
• Add explicit -fPIE (compile) and -pie (link) for the bootgen executable to force a PIE binary even under hostile global flags.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.