Now that I think about it, I would like to clean up the tests before adding test coverage for MSVC. Take for example custom definitions of assert, gmtime_r and localtime_t in test.h. Also, these tests haven't been updated in about 12 years.
Also, since winpthreads is Windows-specific, maybe we could also make use of crtdbg.h for builds with debug CRT? Martin, if you're interested, I have this repo[1] which contains scripts to build some (mostly autotools) packages with MSVC (both cl.exe and clang-cl.exe). It allows to build them with different version of CRT (debug vs. non-debug and static vs. shared). It can be used for testing winpthreads with MSVC locally in the meantime. - Kirill Makurin [1]https://github.com/maiddaisuki/gnu-libs-with-msvc ________________________________ From: Kirill Makurin <[email protected]> Sent: Thursday, October 2, 2025 8:18 PM To: mingw-w64-public <[email protected]> Subject: Re: [Mingw-w64-public] [V2] winpthreads: integrate tests from tests_pthread directory with Automake I was thinking that it'd be nice to test winpthreads with MSVC as well. Also, winpthreads now can be built successfully with MSVC (both cl.exe and clang-cl.exe) using autotools (with exception that /GL[1] options cannot be used with libtool), so the only task is to set up CI for it. I'll look into it later, thank you for the reference. - Kirill Makurin [1] https://learn.microsoft.com/en-us/cpp/build/reference/gl-whole-program-optimization ________________________________ From: Martin Storsj? <[email protected]> Sent: Thursday, October 2, 2025 8:08 PM To: mingw-w64-public <[email protected]> Subject: Re: [Mingw-w64-public] [V2] winpthreads: integrate tests from tests_pthread directory with Automake On Thu, 2 Oct 2025, Kirill Makurin wrote: > When I was writing the patch series I ran the tests locally with 32-bit > msvcrt.dll, 64-bit UCRT (gcc) and 64-bit MSVC. I did not see > pthread_rwlock/rwlock6_t failing. Looking at this test, it seems simple > enough to me. Maybe we can reduce chance of spurious failures by > removing `-j$(nproc)` from winpthreads' `make check`? I had a look now - there's a risk that rdt2 starts executing before wrt1 has released the writelock, and then there's probably no guarantee whether wrt2 or rdt2 gets the lock first? If the sleep between starting wrt2 and rdt2 is increased from 1000 to 1500, there should be less risk for that. Running the tests without -j can of course reduce the risk of such issues, but ideally the testcases themselves should be less brittle so we don't need to do that. > Is there anything left to fix or change? If we're good with this patch > series, could you just replace my 5th patch with yours and remove > "continue-on-error: true" after applying patch 12? (maybe as well remove > `-j$(nproc)`) I can do those changes, yeah. I'm still waiting for review of "Use non-SEH setjmp/longjmp for pthread_cancel arm/aarch64", "Skip the pthread_exit/exit1.c testcase on ARM" and "Reduce the number of threads created in a test on 32 bit" patches that I sent yesterday, though. Then I'd re-read your updated patchset (I haven't read the second round closely yet, I've only applied it and tested it). With those things in place, and if a re-read of the patchset doesn't find anything else problematic, we could indeed apply it. As a separate follow-up wish: As you and others have spent effort in making winpthreads build successfully with MSVC, it would be nice to have some test coverage, or at least build coverage of that as well. Can you look into setting such a configuration up in our github actions? It could be a separate job, not tied to the rest of them. See e.g. https://github.com/mstorsjo/FFmpeg/blob/28e80dc0ffaa5fb1b2f57fb932037fe2c20799fc/.github/workflows/aarch64.yml#L216-L246 for an example of how to make MSVC available (through the ilammy/msvc-dev-cmd step), then msys2/setup-msys2 with "path-type: inherit" to get msys2, while keeping the external global PATH intact, then a job with "shell: msys2 {0}" for an environment where you can run the autotools build. I presume it is possible to build the library through autotools with MSVC somehow? Having such a test setup in place also serves as a documentation of one working configuration of achieving that. // Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
