CMake CheckPIESupported doesn’t always work #30771

1. 
   fanquake commented at 2:10 pm on August 30, 2024: member

   Seen as part of this thread: https://github.com/hebasto/bitcoin/issues/341#issuecomment-2321282757.

   It looks like CMakes https://cmake.org/cmake/help/latest/module/CheckPIESupported.html check isn’t quite the equivalent of what we used to do in Autotools (having -pie and -fPIE as part of our hardened flags), such that now, sometimes the user will need to manually pass flags like -fPIE. In this case, on a FreeBSD system.

   It’s not entirely clear if this is a bug in CMake, or something else, however, we should fix this, as users/developers should not need to manually pass PIC/PIE related flags for working compilation, aside from it being a missing hardening feature.

2. fanquake added the label Build system on Aug 30, 2024
3. fanquake added this to the milestone 29.0 on Aug 30, 2024
4. 
   hebasto commented at 2:17 pm on August 30, 2024: member

   In this case, on a FreeBSD system.

   Mind providing steps to reproduce the issue?

5. 
   fanquake commented at 2:19 pm on August 30, 2024: member

   They can be found in the linked thread: https://github.com/hebasto/bitcoin/issues/341#issuecomment-2316704163. Where passing -fPIE manually is required, otherwise compilation fails.
6. 
   vasild commented at 1:20 pm on September 2, 2024: contributor

   To summarize this: on FreeBSD, but not on Ubuntu and not on Fedora, if the user injects -fprofile-instr-generate -fcoverage-mapping into the compilation/link flags, then CMake wrongly considers that -fPIE is not supported. CMake considers that -fPIE is not supported because it compiles the program without PIE and tries to link with PIE, which on FreeBSD only and only with -fprofile-instr-generate -fcoverage-mapping fails to link (so the test prog fails to link, which means that the PIE test is negative, not that compilation of bitcoin core fails).

   IMO this is low impact and low severity.

7. 
   fanquake commented at 1:27 pm on September 2, 2024: member

   IMO this is low impact and low severity.

   Randomly missing (hardening) flags isn’t that great. The fact that compilation still succeds (is there a warning the check failed?), also means the user is also unaware of the deficiency. We’ve identified one time this happens, but there may also be others. Given the ambiguity, it may also just be easier to return to the previous behaviour of just always using the flags, rather than letting CMake guess, and sometimes get it wrong.

   Is there an issue open upstream?

8. 
   hebasto commented at 2:04 pm on November 21, 2024: member

   Is there an issue open upstream?

   An upstream issue: https://gitlab.kitware.com/cmake/cmake/-/issues/26463.

9. hebasto added the label Upstream on Nov 21, 2024
10. 
    hebasto commented at 3:29 pm on November 26, 2024: member

    The upstream issue has been fixed for CMake 3.32.

Contributors
fanquake hebasto vasild

Labels
Build system Upstream

Milestone
29.0