Ah, you're right. It is indeed the PKGBUILD that deletes the pthread headers when installing https://github.com/msys2/MINGW-packages/blob/16721b39ef3cd7089d7304324d6afc051008772a/mingw-w64-headers-git/PKGBUILD#L60
I do wonder if winpthreads and the mingw-w64-headers do install the headers in the exact same location. Then it might be safe to remove the lines that delete the pthread headers if one is planning to use a different thread model. That would solve the issue with win32 and mcfgthreads in a different way and this patch would be obsolete best regards, Julian On Thu, Oct 10, 2024 at 6:38 PM Martin Storsjö <mar...@martin.st> wrote: > On Thu, 10 Oct 2024, Julian Waters wrote: > > > This allows for gcc with other thread models to use certain standard > > library headers without needing to install winpthreads headers to avoid > > compilation errors. > > That this sounds like a packaging issue to me. I'm not (yet) saying that > we should or shouldn't do this patch that you're suggesting - but we need > to clarify the context and scope of the issue you're trying to address > first. > > The base mingw-w64 headers _do_ contain the headers pthread_time.h, > pthread_signal.h and pthread_unistd.h - as near-empty dummy headers. If > you just install mingw-w64-headers and not winpthreads, and build GCC with > the win32 thread model, then including e.g. time.h works just fine - it > includes the dummy empty pthread_time.h. This has worked this way for a > very long time, otherwise there would probably be massive breakage all > around. > > Then if you do install winpthreads on top, it overwrites those dummy > headers with a proper functional version of them. > > I believe the fact that the same header can be sourced from two locations, > which looks like a conflict, is the reason why some package repos perhaps > may choose to omit the pthread_*.h headers from the base package, as > they're expected to be provided by another package. > > So there is no such issue that one can't use GCC with a different thread > model, without winpthreads. Such an issue is primarily caused by your > packaging of the headers. > > Then secondly, whether pthread_time.h should be included by time.h is > unrelated to the thread model. The thread model is mostly a GCC internal > detail anyway, affecting how libgcc behaves. > > The reason for pthread_time.h being included in time.h, is because > winpthreads is the library that provides nanosleep and clock_gettime etc - > and those functions are documented to be provided by time.h. But if we go > forward with this patch, a build using the win32 thread model would no > longer be able to use nanosleep() or clock_gettime() just by including > time.h as they did before. > > // Martin > > > > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
