On Sun, 1 May 2022, LIU Hao wrote:
On Sun, 1 May 2022, JonY via Mingw-w64-public wrote:
I think dllexport should be replaced by dllimport in the above statement.
Yes it was a typo. Revised patch attached.
On Sun, May 1, 2022 at 9:36 AM Martin Storsjö <[email protected]> wrote:
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.
That concerns me too. I still prefer the previous patch which removes
`dllimport` entirely, because it is consistent between EXEs and DLLs and is
less verbose, unless there are bugs about the auto-import feature.
As expected, this patch did break a number of use cases. One of them is
that VLC fails to build, as it links winpthreads statically in a number of
cases; all of those would now have to be built with -DWINPTHREAD_STATIC.
However, it also breaks another case, which cannot be fixed that simply,
which shows why this patch must be reverted/reworked.
Building a plain simple C++ source file fails, if passing "-static" to
the linking command, as libstdc++ was built with winpthread headers
that defaulted to dllimport.
This can't be fixed by the user of the toolchain (who is the one wanting
to build a mostly static executable), as libstdc++ already was built when
building the toolchain. And exactly which combination of libraries that
end up linked isn't fixed either; normally, it'd link against a dynamic
libstdc++ (which is linked against a dynamic winpthreads). If passing
-static-libstdc++, it'd link libstdc++ statically, but link against a
dynamic winpthreads. If passing -static, it links both libstdc++ and
winpthreads statically - which is what now breaks.
I don't mind reversing the logic though; we could add a
WINPTHREAD_DLLIMPORT define, for users who really want to explicitly use
dllimport, to avoid the negligible overhead of DLL call thunks.
But winpthreads should default to not using dllimport, which is how it has
worked when used in most cases, e.g. from within libstdc++, everywhere so
far.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
