BUG: _ZSt28_throw_bad_arrray_new_lengthv on GNU 137 but not MSVC 130

[Joebugg]

Describe the bug
Error message on upgrade.

To Reproduce
Steps to reproduce the behavior:
Install latest VCRT (1438).
Copy QSV 130 to somewhere in path or add path to installed location.
Run QSV 130 exe.
Accept offer to upgrade.
Run QSV 137.
Get following error message:
"The procedure entry point _ZSt28_throw_bad_arrray_new_lengthv could not be located in the dynamic link library C:\Program Files (x86)\gnuwin32\bin\qsv.exe."

Expected behavior
It to list options and return to command prompt when done.

Desktop (please complete the following information):
Windows Server 2019 64-bit
Both x64 and x86 runtimes updated to latest from Microsoft (2015-2022 support).

Additional context
I'm going to try moving it directly to the folder where I'm running the command from. I suspect it's mixing DLL versions if one is found in GnuWin32's path, before VC's.

[Joebugg]

Renamed libstdc++-6.dll (which was needed for QSV 130), and now it's no longer giving the ZSt28 error, but now it wants a compatible libstdc++ library. I assume there's a newer version of libstdc++-6.dll that is compatible with QSV and current runtimes?

[jqnatividad]

I'm afraid I don't have access to a Windows Server 2019 64-bit machine so it'll be hard to troubleshoot.

Can you share what qsv --version shows for the currently installed qsv?

[Joebugg]

I'll try reverting back through versions to narrow it down. It won't let me get that far, to show the version info, but I let it update to latest. Hex editor and hash of F8531339 verify that it's same as qsv.exe in qsv-0.137.0-x86_64-pc-windows-gnu.zip.
Hmm, seems there's both a MSVC and Gnu version. The MS runtimes would thus have zero effect? I'll try hunting down the Gnu runtimes.

[Joebugg]

Reverted back to 130 and now it does it, too.

EXE I had copied from other PC that works:
qsv 0.130.0-mimalloc-apply;fetch;geocode;Luau 0.635;to;polars-0.41.3;self_update-4-4;6.24 GiB-2.84 GiB-2.89 GiB-7.80 GiB (x86_64-pc-windows-msvc compiled with Rust 1.79) prebuilt
EXE that I just downloaded: Displays nothing and returns to command line (even with --version or --list).

Ah, so the problem is library version/support. So if I used the MSVC exe, it'll work, fine. Begs the question how you get the correct Gnu runtimes...

Installation notes should probably mention version of compiler used (MinGW?) so that others don't have this issue.
Also, not a bad idea to not update to a different main line with that --update command? I guess the three main ones on Windows are GNU/MSVC/Rust.

[jqnatividad]

Thanks for the thorough investigation @Joebugg .

I'll add an installation note per your suggestion.

Thinking about it more, maybe I should just prune the choices and stop building GNU version on Windows and just use MSVC. WDYT?

https://www.reddit.com/r/rust/comments/a63dlt/difference_between_the_gnu_and_msvc_toolchains/

[Joebugg]

I wonder if it makes more sense to offer it as a file you can just run the build tool on, in GCC. What kind of dependencies are we talking about?
I mean, you kind of need the right compiler's library (AFAICT, there's multiple with the same filename?) to use it, anyways.
Is it possible to legally include the standard library (or at list, link to correct one)?

GNU version sounds good but if I can't use it... As a user, that does me no good. MSVC has it's own annoyances like incompatibilities because of one pointless function call that you can't (easily?) disable on newer Visual Studio versions, so if you want a program to work on everything from NT 3.5 to 11, you have to make multiple versions. Not that I'd want to be using 2000 or XP anymore. ;)

To the average user, the only appreciable difference is that they install different set of runtime libraries. I assume there's some performance differences or convenience factors as well.

[jqnatividad]

The GitHub Action Publishing workflow uses windows-latest:
https://github.com/jqnatividad/qsv/blob/2b5536084f42acfea4422797abcf3396074f856e/.github/workflows/publish.yml#L88-L97

And per GH, windows-latest is windows-2022 which may very well be the root cause of your specific problem.
That image has the bundled libraries qsv uses:
https://github.com/actions/runner-images?tab=readme-ov-file#available-images

I'll add that to the note. And maybe, add another variant that uses windows-2019 or just pin qsv windows gnu to always be more conservative and not use windows-latest...