Fix for Issue #1600 - Fixed Windows Installation - Windows: bundle MinGW runtime DLLs recursively (fixes missing OpenSSL dlls)

[shreyas-malhotra]

The Windows portable build and NSIS installer were missing runtime DLLs provided by MinGW, specifically OpenSSL 3 (libcrypto-3-x64.dll, libssl-3-x64.dll). This caused the installer build to fail at runtime on clean Windows systems.

This change updates the Windows dependency bundling step to:

• Use ntldd -R (when available) to recursively resolve PE dependencies
• Copy all MinGW runtime DLLs into the portable directory
• Fall back to ldd if ntldd is not available (e.g. clangarm64)

No workflow changes were made. The fix is limited to the __windows_copy_deps target in the Makefile.

Results:

• OpenSSL runtime DLLs are now bundled correctly.
• The Windows installer launches on clean systems without requiring MSYS2 or a system OpenSSL installation.
• Reduces risk of future missing DLL issues due to indirect dependencies.

Fixes: #1600

Demonstration of Tuba running on Windows 11:

[GeopJr]

LGTM overall, thanks!

For the sake of confirming that the CI also did it right, could you give the CI artifacts a try?

The Windows installer launches on clean systems without requiring MSYS2 or a system OpenSSL installation.

(FWIW, as I said in that issue too, my windows environment is windows 10 iot and as it is now, the windows builds of Tuba worked as expected. I made sure multiple times by installing it without msys2 on the system at all and in VMs etc. I never tested on Windows 11 so I have no idea why it requires OpenSSL explicitly.)

[shreyas-malhotra]

For the screenshot that I submitted with the PR, I installed Tuba using the artifact "Tuba Setup.exe" from the final CI run.

Tested the portable x86 binary as well just now, and it works as expected.

Couldn't check the portable aarch64 files though since I don't have an arm device running Windows.

[shreyas-malhotra]

Also just followed you on Mastodon! 🐘

[GeopJr]

Awesome, thanks!

[GeopJr]

Sorry, one last question

Add conditional check for ntldd command in Makefile, since ntldd was missing in workflow

Is it missing in the CI or not? If it is, we can just install it

[shreyas-malhotra]

Sorry, one last question

Add conditional check for ntldd command in Makefile, since ntldd was missing in workflow

Is it missing in the CI or not? If it is, we can just install it

It was missing in the CI, so I wrote a simple check for it, if the check fails it runs an alternative command using ldd instead.

If we do install ntldd, best practice would then be to run CI again and verify that the build works with the ntldd command as well, or to simplify things we can just omit the ntldd command and the condition that checks for it, and just keep the revised ldd command in place, which is verified to work since ntldd wasn't present in the CI runs.

[GeopJr]

hmm, I'm a bit confused here.

Prior to your changes, we already ran the exact same ldd command, which apparently missed OpenSSL for Windows 11. So if ntldd is missing in the CI, how come the CI artifact works on Windows 11 if technically nothing changed (since it ran the previous ldd command)?

[shreyas-malhotra]

hmm, I'm a bit confused here.

Prior to your changes, we already ran the exact same ldd command, which apparently missed OpenSSL for Windows 11. So if ntldd is missing in the CI, how come the CI artifact works on Windows 11 if technically nothing changed (since it ran the previous ldd command)?

I'll have a look at it then, I guess.

[GeopJr]

Don't worry about it, I'll just add it to the CI just to be safe

[shreyas-malhotra]

Ah I think I found what the issue was, ntldd seems to be missing from the aarch64 CI environment, but present in the x86 one, so my earlier CI run (first commit) that failed still might have worked fine for x86 since ntldd was present and it used that.

And in my second commit, after I added the conditional check, it used ntldd for the x86 run and fell back to ldd for the aarch64 run (since the ntldd conditional check failed), which makes me suspect that the aarch64 portable release might still have the same issue if it is using the same ldd command as before.