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

Reply via email to