I would like to mention that `WINPTHREAD_API` for `__pth_gpointer_locked` does
not make sense to me. The `WINPTHREAD_API` expands into `declspec(dllexport)`
when building the shared library, however `__pth_gpointer_locked` seems to be
an internal function.
Also, the `__pth_gpointer_locked` is also declared in `winpthread_internal.h`
and also has `WINPTHREAD_API`. Maybe it would be proper to remove
`WINPTHREAD_API` from both declarations?
________________________________
From: Jonathan Yong <10wa...@gmail.com>
Sent: Thursday, January 30, 2025 8:20 PM
To: mingw-w64-public@lists.sourceforge.net
<mingw-w64-public@lists.sourceforge.net>
Subject: Re: [Mingw-w64-public] winpthreads and MSVC
On 1/30/25 3:02 AM, Kirill Makurin wrote:
> Yes, no problem.
>
> I also had a patch for Makefile.am which tried to solve the alias issue by
> copying `[lib]winpthreads[.dll].{lib|a}` as `[lib]pthread[.dll].{lib|a}`
> during installation. I can send it again.
>
> I see. I could maintain a GitHub repository with a copy of winpthreads, but
> with Meson and possibly CMake build systems. I think this could be useful.
The 2 patches look OK to me, I'll wait for feed back from the others.
As for copying, if it is to be done in autotools, I prefer a new option
such as --enable-compat-copy to be enabled explicitly for the copies to
be made, to avoid surprising existing users when updating.
Making a github copy with appropriate Meson and CMake infrastructure
added is fine with me.
_______________________________________________
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
