Run dumpbin.exe /imports on the cross-built bitcoind.exe in the "Windows, test cross-built" jobs to list the imported DLLs and to ensure the executable is linked against the expected C runtime.
This came up during a discussion in #35877 (here and here). Inspired by the analogous CI steps in https://github.com/hebasto/bitcoin-core-nightly.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35931.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline and AI policy for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | maflcko, jeanpablojp |
If your review is incorrectly listed, please copy-paste <code><!--meta-tag:bot-skip--></code> into the comment that the bot should ignore.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
Run `dumpbin.exe /imports` on the cross-built `bitcoind.exe` in the
"Windows, test cross-built" jobs to list the imported DLLs and to
ensure the executable is linked against the expected C runtime.
lgtm ACK 67fee5bf440c24eb708bfc40da46c23595e5a4f4
ACK 67fee5bf440c24eb708bfc40da46c23595e5a4f4
I have tested the code: I ran check_imports from the branch against a stand-in dumpbin.exe fed with this PR's own CI output (run 31188572449). The parsed list matches what both jobs printed, and the cases CI does not reach fail as they should: wrong CRT either way, both runtimes at once, and an empty DLL list all exit 1. So the check fails closed if dumpbin's output format ever changes.