Wesnoth crashes silently with VS2019 builds on Windows 7 (boost::iostreams::tee)

[Wedge009]

Game and System Information

• Version: 1.17.18 onwards
• Downloaded from: GitHub
• Build info: Self-compiled with VS2019
• OS: Windows 7

Description of the bug

For a while I've been wondering why my builds of 1.17 don't work on Windows 7. After some investigation I've discovered the following:

• Wesnoth master compiled with VS2019 on Windows 7 fails to start. Log file is created but it remains empty.
• Wesnoth master compiled with VS2019 on Windows 7 with --no-log-to-file runs successfully.
• Wesnoth master compiled with VS2019 on Windows 7 in debug mode runs without issue in any logging mode.
• Official Wesnoth 1.17 Windows release runs on Windows 7 without issue.
• Wesnoth master compiled with VS2022 on Windows 10 runs without issue.
• Wesnoth master compiled with VS2019 on Windows 7 run through the debugger (but obviously without being able to set break-points) logs assertion errors at: https://github.com/boostorg/iostreams/blob/6be38c3449a64b15213c6a490d357c9a2ac2470b/include/boost/iostreams/tee.hpp#L176
• The previous point led me to try reverting Write log output both to stderr and logfile at the same time #7672. Wesnoth master with Write log output both to stderr and logfile at the same time #7672 reverted, compiled with VS2019 on Windows 7, runs without issue.

Steps to reproduce the behavior

Compile Wesnoth master after 25afcb3 using VS2019 on Windows 7. Run release-build Wesnoth without debugging and leaving the default setting of log-to-file, observe no Wesnoth window, no Wesnoth process in the Task Manager, and an empty log file time-stamped at the time of running.

Expected behavior

Wesnoth runs as normal.

Additional context

I set this to low priority because it really only affects developers using MSVC on Windows 7 (maybe only me?). Official Windows builds are unaffected.

Really don't know what's going on, whether it's an issue with optimised release-builds from VS2019 (since debug-builds are okay), something specific in Windows 7, something wrong with how boost implements tee on Windows 7, or something else entirely. Running with --no-log-to-file obviously bypasses the use of tee, which is why it runs okay in that scenario.

I'm okay for this to be closed, as 'won't fix', I'm just logging for information purposes, as I did with other MSVC-specific oddities like #6171.

[Wedge009]

I only just noticed the minimum requirements for 1.17.x on wesnoth.org has been updated to Windows 10. Which I only noticed after finding official Windows release for 1.17.24 fails to start on Windows 7 due to missing libssp-0.dll. Looks like 1.17.23 is the last build that will run on Windows 7.

@Pentarctagon or whoever else knows: what feature needed the change in requirements? I may have been told before, but I forgot.

[Pentarctagon]

Does it start on Windows 10?

[CelticMinstrel]

My opinion is probably in the minority, but… I think it's not unreasonable to continue to support running on Windows 7. That's much easier than trying to support building on Windows 7. Maintaining compatibility with older versions of Windows is much easier than it is for MacOS, so if it can be done with just a minor change to the code or the build process, then I think we might as well do it.

[Pentarctagon]

I mean that the dlls are added as part of the process of building the installer package. Especially since libssp is apparently some sort of GCC helper library, I wouldn't expect Windows to have that natively, so if it's missing then it's probably a problem regardless of Windows version?

[CelticMinstrel]

True, that's a definite possibility.

[Wedge009]

Does it start on Windows 10?

Oh dear, no it doesn't. #8132

My opinion is probably in the minority, but… I think it's not unreasonable to continue to support running on Windows 7.

I had hoped that to be the case too. I think it's fine to leave this closed, but I was wondering about the minimum requirements listed for 1.17 on wesnoth.org:

Microsoft Windows 10 1903 (64-bit) or later

Especially since libssp is apparently some sort of GCC helper library...

Yeah, I see now it seems to be related to MinGW/MSYS2, not Windows 10 vs Windows 7.

[Pentarctagon]

The minimum there is because it's required for installing Wesnoth into a directory with a path containing non-ascii characters. Otherwise there's nothing I know of which would prevent Wesnoth from working on Windows 7.

[Pentarctagon]

@Wedge009 if you re-add libssp, does it work on Windows 7? Also does the log file get written?

[Wedge009]

The minimum there is because it's required for installing Wesnoth into a directory with a path containing non-ascii characters. Otherwise there's nothing I know of which would prevent Wesnoth from working on Windows 7.

Oh, that issue. I forgot about that. That was from the switch to fontconfig, wasn't it?

Where would/should I get libssp-0.dll from? Edit: found some candidates - see my comment in #8132.

Regarding logs being written - they are fine when running the official releases. The log issue I reported here is specific to when I compile Wesnoth myself.

[Wedge009]

Resolved by #8391.