cmake: fatal error when PIE not supported #33282

1. 
   stickies-v commented at 1:22 pm on September 2, 2025: contributor

   This simultaneously avoids silently overriding user preferences while making it harder to accidentally build without PIE support by requiring an explicit setting.

   This introduces two behaviour changes:

   1. a user-defined CMAKE_POSITION_INDEPENDENT_CODE=OFF will now be respected by our build system, instead of silently overriding it like before
   2. when not explicitly disabled, lack of PIE support will raise a FATAL_ERROR instead of a WARNING, with a help instruction that this can be overridden with -DCMAKE_POSITION_INDEPENDENT_CODE=0

   Removes a dependency on our custom configure_warnings system.

2. DrahtBot added the label Build system on Sep 2, 2025
3. 
   DrahtBot commented at 1:22 pm on September 2, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33282.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #33390 (cmake: exclude secp256k1 from all by purpleKarrot)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

4. 
   hebasto commented at 2:35 pm on September 2, 2025: member

   cc @purpleKarrot @theuni
5. 
   purpleKarrot commented at 3:48 pm on September 3, 2025: contributor

   Where is it defined or documented why CMAKE_POSITION_INDEPENDENT_CODE is set to ON in the first place?

   A better approach would be to not override user preferences at all and set the POSITION_INDEPENDENT_CODE target property explicitly on targets that need it.

6. stickies-v force-pushed on Sep 3, 2025
7. 
   stickies-v commented at 4:23 pm on September 3, 2025: contributor

   A better approach would be to not override user preferences at all

   Thanks for the review. I think I agree. I already tried to improve that behaviour by not overriding CMAKE_POSITION_INDEPENDENT_CODE when it was set by the user, but it seems better to not change it at all, as you say.

   I’ve force-pushed to use our existing core_interface to propagate INTERFACE_POSITION_INDEPENDENT_CODE to all our targets, since I think the current behaviour of using PIE for all targets is sensible. What do you think about this approach?

8. 
   purpleKarrot commented at 4:36 pm on September 3, 2025: contributor

   I think the current behaviour of using PIE for all targets is sensible

   I am not convinced and I really would like to know the rationale for that. Maybe @hebasto or @theuni knows?

9. cmake: fatal error when PIE not supported

   This simultaneously avoids silently overriding user preferences while
   making it harder to accidentally build without PIE support by requiring an
   explicit setting.
   
   This introduces two behaviour changes:
   1. a user-defined `CMAKE_POSITION_INDEPENDENT_CODE=OFF will now be
      respected by our build system, instead of overriding it like before
   2. when not explicitly disabled, lack of PIE support will raise a
      FATAL_ERROR instead of a WARNING
   
   Removes a dependency on our custom configure_warnings system.

   917d7461c0
10. stickies-v force-pushed on Sep 3, 2025
11. 
    davidgumberg commented at 0:03 am on September 12, 2025: contributor

    I think the current behaviour of using PIE for all targets is sensible

    I am not convinced and I really would like to know the rationale for that. Maybe @hebasto or @theuni knows?

    For motivation, you can look to the commit which enabled PIE by default: https://github.com/bitcoin/bitcoin/commit/3f94dfa25fc1b0e838d368a9b2683a634c.

    In order for operating systems employing ASLR to randomize the base address of an executable’s text segment, binaries must be built as PIE, and this behavior is a desirable mitigation of memory vulnerabilities.

12. 
    stickies-v commented at 1:32 pm on October 14, 2025: contributor

    Closing for lack of reviewer interest, it’s not a critical change.
13. stickies-v closed this on Oct 14, 2025

    ---

Contributors
stickies-v DrahtBot hebasto purpleKarrot davidgumberg

Labels
Build system