backport: bitcoin/bitcoin#28461: build: Windows SSP roundup

[knst]

Issue being fixed or feature implemented

Fixes undeterminism for windows build

What was done?

Original backport description:

f95af98 guix: default ssp for Windows GCC (fanquake)
95d55b9 guix: remove ssp workaround from Windows GCC (fanquake)
8f43302 build: remove explicit libssp linking from Windows build (fanquake)

I was expecting this to fail to compile somewhere, maybe in the CI, but that doesn't seem to be the case?
Seems workable given the SSP related changes in the newer mingw-w64 headers (which are in Guix):

Implement some of the stack protector functions/variables so -lssp is now optional when _FORTIFY_SOURCE or -fstack-protector-strong is used.

However I think this would still be broken in some older environments, so we might have to wait for a compiler bump, or similar. The optional -lssp also seems to work when using older headers, which doesn't make sense.

How Has This Been Tested?

Run multiple guix build - hashes matched

Breaking Changes

n/a

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone

[github-actions]

✅ No Merge Conflicts Detected

This PR currently has no conflicts with other open PRs.

[PastaPastaPasta]

utACK 32ad4a7b3885f42b50fdaa2dc241af08e43cead0

[DashCoreAutoGuix]

Guix Automation has began to build this PR tagged as v23.0.0-devpr6889.32ad4a7b. A new comment will be made when the image is pushed.

[coderabbitai]

Walkthrough

• Removed a MinGW-specific libssp runtime check from configure.ac that performed AC_CHECK_LIB([ssp], [main], [], [AC_MSG_ERROR([libssp missing])]) inside a case $host in *mingw*) block, eliminating the explicit configuration-time error when libssp is absent on MinGW targets.
• Updated contrib/guix/manifest.scm:
  • For mingw-w64-base-gcc, removed the gcc_cv_libc_provides_ssp=yes patch logic and added --enable-default-ssp=yes to configure arguments.
  • For linux-base-gcc, added configure flags --enable-initfini-array=yes, --enable-default-ssp=yes, --enable-default-pie=yes, --enable-standard-branch-protection=yes, and --enable-cet=yes, and introduced a pre-configure phase that replaces -rpath with -rpath-link in GCC config files.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.
Title Check	✅ Passed	The title identifies this PR as a backport of upstream PR 28461 and succinctly describes its focus on Windows SSP build adjustments. It avoids vague wording and clearly highlights the main change without unnecessary file lists or emojis. This should allow teammates scanning the history to grasp the purpose at a glance.
Description Check	✅ Passed	The pull request description directly addresses the removal of explicit libssp linking for Windows builds, references the relevant backported commits, explains the expected and observed build behavior, and details the testing performed, making it clearly related to the changeset.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Warning

Review ran into problems

🔥 Problems

Git: Failed to clone repository. Please run the @coderabbitai full review command to re-trigger a full review. If the issue persists, set path_filters to include or exclude specific files.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

contrib/guix/manifest.scm (1)

455-461: Verify the rpath to rpath-link substitution.

The pre-configure phase replaces -rpath= with -rpath-link= in GCC config files. This changes linker behavior:

• -rpath embeds runtime library search paths into the binary
• -rpath-link only affects link-time library resolution

Verify that this substitution doesn't cause runtime library resolution issues for binaries built with this toolchain.

Consider documenting the rationale for this substitution in a comment, as it's a subtle but important change to the linker behavior:

 (add-after 'pre-configure 'replace-rpath-with-rpath-link
(lambda _
+ ;; Replace -rpath with -rpath-link to avoid embedding Guix store paths+ ;; in the runtime library search path, while still allowing link-time resolution
(substitute* (cons "gcc/config/rs6000/sysv4.h"
(find-files "gcc/config"
"^gnu-user.*\\.h$"))
(("-rpath=") "-rpath-link="))
#t))))

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2350339 and 32ad4a7b3885f42b50fdaa2dc241af08e43cead0.

📒 Files selected for processing (2)

• configure.ac (0 hunks)
• contrib/guix/manifest.scm (1 hunks)

💤 Files with no reviewable changes (1)

• configure.ac

🧰 Additional context used

📓 Path-based instructions (1)

contrib/**

📄 CodeRabbit inference engine (CLAUDE.md)

Unless specifically prompted, avoid making changes to the contrib directory (contributed scripts)

Files:

• contrib/guix/manifest.scm

🔇 Additional comments (2)

contrib/guix/manifest.scm (2)

434-435: LGTM: Windows SSP enabled by default in GCC.

The addition of --enable-default-ssp=yes aligns with the PR objective to enable stack smashing protection by default in the Windows GCC configuration, eliminating the need for explicit libssp linking.

---

445-450: Verify architecture-specific hardening flags.

The configure flags --enable-standard-branch-protection (ARM-specific, requires ARMv8.5-A+) and --enable-cet (x86-specific, Intel CET) are architecture-dependent. Ensure these flags are compatible with all target architectures that use this GCC configuration, or that the GCC configure script gracefully handles them on unsupported platforms.

Run the following script to check which cross-compilation targets use linux-base-gcc:

[UdjinM6]

utACK 32ad4a7b3885f42b50fdaa2dc241af08e43cead0

[knst]

wait guix build! maybe it won't succeed

build failed :(

[PastaPastaPasta]

 CXX evo/libbitcoin_node_a-evodb.o
depends/relic/src/md/relic_md_mgf.c: In function 'md_mgf':
depends/relic/src/md/relic_md_mgf.c:43:6: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector]
43 | void md_mgf(uint8_t *key, int key_len, const uint8_t *in,
| ^~~~~~
CC depends/relic/src/md/librelic_la-relic_md_sha224.lo
CC depends/relic/src/md/librelic_la-relic_md_sha256.lo
CC depends/relic/src/md/librelic_la-relic_md_sha384.lo
CC depends/relic/src/md/librelic_la-relic_md_sha512.lo
CC depends/relic/src/md/librelic_la-relic_md_xmd.lo
CC depends/relic/src/md/librelic_la-sha224-256.lo
CC depends/relic/src/md/librelic_la-sha384-512.lo
CXX evo/libbitcoin_node_a-mnauth.o
CC depends/relic/src/mpc/librelic_la-relic_mt_mpc.lo
CC depends/relic/src/mpc/librelic_la-relic_pc_mpc.lo
CXX evo/libbitcoin_node_a-mnhftx.o
CXX evo/libbitcoin_node_a-providertx.o
CCLD libmimalloc-secure.la
CXX evo/libbitcoin_node_a-simplifiedmns.o
CCLD librelic.la
CXXLD libdashbls.la
libtool: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries; building static only
CXX evo/libbitcoin_node_a-smldiff.o
CXXLD runtest.exe
CXX evo/libbitcoin_node_a-specialtx.o
x86_64-w64-mingw32-ld: /gnu/store/szyy6ig6kbgj3hdjwf1djypn6q2gypjw-gcc-cross-x86_64-w64-mingw32-12.4.0-lib/x86_64-w64-mingw32/lib/../lib/libssp.a(ssp.o):(.text+0xf0): multiple definition of `__stack_chk_fail'; /gnu/store/szyy6ig6kbgj3hdjwf1djypn6q2gypjw-gcc-cross-x86_64-w64-mingw32-12.4.0-lib/x86_64-w64-mingw32/lib/../lib/libssp.dll.a(libssp_0_dll_d000007.o):(.text+0x0): first defined here
CXX evo/libbitcoin_node_a-specialtx_filter.o
CXX evo/libbitcoin_node_a-specialtxman.o
CXX governance/libbitcoin_node_a-classes.o
CXX governance/libbitcoin_node_a-exceptions.o
CXX governance/libbitcoin_node_a-governance.o
CXX governance/libbitcoin_node_a-object.o
CXX governance/libbitcoin_node_a-validators.o
CXX governance/libbitcoin_node_a-vote.o
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:3247: runtest.exe] Error 1
make[3]: Leaving directory '/distsrc-base/distsrc-23.0.0-rc.1-8-g32ad4a7b3885-x86_64-w64-mingw32/src/dashbls'
make[2]: *** [Makefile:23826: dashbls/libdashbls.la] Error 2
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/distsrc-base/distsrc-23.0.0-rc.1-8-g32ad4a7b3885-x86_64-w64-mingw32/src'
make[1]: *** [Makefile:21421: all-recursive] Error 1
make[1]: Leaving directory '/distsrc-base/distsrc-23.0.0-rc.1-8-g32ad4a7b3885-x86_64-w64-mingw32/src'
make: *** [Makefile:793: all-recursive] Error 1

[DashCoreAutoGuix]

Guix Automation has completed; a release should be present here: https://github.com/dashpay/dash-dev-branches/releases/tag/v23.0.0-devpr6889.32ad4a7b. The image should be on dockerhub soon.

[DashCoreAutoGuix]

Guix Automation has began to build this PR tagged as v23.0.0-devpr6889.85d2f1f3. A new comment will be made when the image is pushed.

[thephez]

Builds successfully for me 👍

d5958e4fd838a7b14a7d3e80a63e6b37fe4efd9c40e975cc0fe0e3f1fdb6eec5 dist-archive/dashcore-23.0.0-rc.1-9-g85d2f1f33600.tar.gz
be9d5141e1654529e29b5905b25751da0bb699ebeecbe26b8695d23d48330c9d x86_64-w64-mingw32/dashcore-23.0.0-rc.1-9-g85d2f1f33600-win64-debug.zip
fe7ed8447aefa964d7370aa92ae855fc9d589cac64633e863109a3589b62449a x86_64-w64-mingw32/dashcore-23.0.0-rc.1-9-g85d2f1f33600-win64-setup-unsigned.exe
cf5ed4d38c08b75812285afd39a1cf19eb6e509af9385e981296f94ae9713f47 x86_64-w64-mingw32/dashcore-23.0.0-rc.1-9-g85d2f1f33600-win64-unsigned.tar.gz
e4ec89e9140d1d5eca436d37c5dff84084a8b2da4b4d63b5bf43993b06170704 x86_64-w64-mingw32/dashcore-23.0.0-rc.1-9-g85d2f1f33600-win64.zip

[DashCoreAutoGuix]

Guix Automation has completed; a release should be present here: https://github.com/dashpay/dash-dev-branches/releases/tag/v23.0.0-devpr6889.85d2f1f3. The image should be on dockerhub soon.

[UdjinM6]

utACK f8d4a48

[kwvg]

utACK f8d4a48

[thephez]

utACK f8d4a48

5946705118d0ac0ddca9e34bac01da04c436672141d097d8606362cdf116e021 x86_64-w64-mingw32/dashcore-23.0.0-rc.1-20-gf8d4a485bf9a-win64-debug.zip
7f0fa91b5febe0c2fa998123b3c8e2e483975e1001529b27e822463483451a18 x86_64-w64-mingw32/dashcore-23.0.0-rc.1-20-gf8d4a485bf9a-win64-setup-unsigned.exe
bdb2b7534cfe3182274cd6a34be3aea7c27e56132eaadef29b16f11f2bd934ec x86_64-w64-mingw32/dashcore-23.0.0-rc.1-20-gf8d4a485bf9a-win64-unsigned.tar.gz
65b82e22eeafde63d917330d98558b2a4372cb0d5be523dcf9889447fb98c8ec x86_64-w64-mingw32/dashcore-23.0.0-rc.1-20-gf8d4a485bf9a-win64.zip```