On 10.10.2024 13:15, Martin Storsjö wrote:
On Thu, 10 Oct 2024, Julian Waters wrote:
Ah, you're right. It is indeed the PKGBUILD that deletes the pthread
headers
wheninstallinghttps://github.com/msys2/MINGW-packages/blob/16721b39ef3cd7089d73
04324d6afc051008772a/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
I think they probably are installing the headers in the same location;
otherwise you'd have to make sure that it does prefer the winpthreads
version of the header anyway.
If we could require reasonably recent compilers for accessing things
like clock_gettime() and nanosleep() etc, we could remove the dummy
headers from mingw-w64-headers, and use __has_include() instead. From
a quick browsing of GCC docs, it's available since GCC 9.
We can check for #ifdef __has_include, to see if the compiler supports
it - and then we could fall back to not including pthread_time.h if
using an older compiler. It's not the best solution, but could maybe
be a reasonable way to get the setup with
dummy/overwritten/conflicting headers improved.
If we need to support such configs, this sounds reasonable. But, as you
pointed out, it seems like a packaging issue in the first place. And in
any case, coupling it with GCC threading model does not sounds right to
me too.
That said - for a non-pthreads thread model GCC, or with Clang, one
has to manually link against winpthread to practically use nanosleep()
or clock_gettime(), as that's not linked implicitly except for when
GCC uses it for the libgcc thread model.
One may wonder why those functions are in winpthread at all, rather
than in e.g. libmingwex like many other compatibility additions we
have. I think there may be some interaction with other pthread
facilities though... Not sure if this is a direction worth going into,
or if it just changes things that already have got an established way
of working.
FWIW, I've never been a fun of how winpthread is interacting with
mingw-w64-headers and something like that could potentially get rid of
this weird dependency (I assume that we'd then move pthread_* headers to
mingw-w64-headers too). nanosleep seems to depend on winpthread
internals, but maybe we could have a simpler implementation in crt and
winpthread could override it if it really needs to. I'm not sure, the
current solution seems to work well in practice after all.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
