On Sun, May 1, 2022 at 9:36 AM Martin Storsjö <[email protected]> wrote: > > On Sun, 1 May 2022, JonY via Mingw-w64-public wrote: > > > On 5/1/22 05:19, LIU Hao wrote: > >> 在 2022-05-01 13:15, LIU Hao 写道: > >>> This is the alternative patch as discussed with jon_y on IRC. > >>> > >>> > >> > >> I forgot to update the commit message. Here is the revised patch. > >> > > > > +Programs are usually linked against the winpthreads DLL, and winpthreads > > +headers expose `dllexport` APIs by default. When linking against the > > +static library, especially when building a user DLL with libtool, it is > > +necessary to define the `WINPTHREAD_STATIC` macro to avoid undefined > > +references. > > > > I think dllexport should be replaced by dllimport in the above statement. > > > > Building a DLL with dllexport marked symbols is correct and expected. > > The problem comes in when dllimport is used when the user intentionally > > wants to link to a static library, hence they need to add > > -DWINPTHREAD_STATIC to signal that they do actually want it so. > > FWIW, I think this will break a number of users, who currently > successfully are linking statically, who now need to set a winpthread > specific define to make it work. Yes, they can change their setups to > manually define WINPTHREAD_STATIC, but it will cause lots of extra > inconvenience for users with setups that so far have worked just fine. > > But if you really really prefer this setup, then fine, go ahead. But I did > warn that it will inconvenirnce users.
should winpthread be used by users ? i thought it was written for c++11 threads Vincent Torri _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
