Hi Martin,
Sorry for the delay.
On 04.01.2021 21:16, Martin Storsjö wrote:
Hi,
On Mon, 4 Jan 2021, Jacek Caban wrote:
FWIW, I think that the attached patch should do the right thing on
VLC (but I don't really have setup to test it).
Thanks, looks like that could be enough - I'll try to get time to
think through and test the potential combinations.
A different case that came to mind now is ffmpeg;
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=900505756bf6fb734708da6278689037157fc53a;hb=0cd8769207f1a89fc2236aab9da1c77f5a0b490a#l5628
I guess the fix here would be to do the check without including a
header first, to check whether it was defined in cflags. Then again, I
just checked building with -D_WIN32_WINNT=0xA00, and the binary
started on Vista, so there doesn't seem to be any configure tests for
features above that anyway.
ffmpeg use seems fine to me. They just make sure that it's high enough
to have required declarations available. It doesn't seem to make any
runtime decision based on _WIN32_WINNT value.
It sounds lime msys2 will not be affected. I don't mind waiting with
committing this patch if helps. I only think that it would be good to
commit relatively early in release cycle so that we have time to
address feedback.
At this point, I don't think there's need to wait any more; it'd
better to get it out there and see what it breaks, if anything, sooner
rather than later. (And my setups already override it to win7 anyway,
but I guess I could consider leaving it to the default if it's higher.)
Sounds good to me, I pushed the commit.
I also faintly remember somebody suggesting that we'd formally
drop support for XP altogether.
FWIW, that sounds about right to me, but I didn't want to make this
change about dropping XP support. I guess that what we're missing
is some form of discussion and formalizing it, if that's the
consensus.
Yeah, that's probably a separate discussion. And before doing it, I
guess we should quantify what we actually gain from it, instead of
just doing it for the sake of doing it. Being able to rely on more
features in msvcrt.dll (for setups that use it) probably would be
one thing.
I'd be tempted to consider defaulting to UCRT, but I realize that it
has serious compatibility implications. If we decided to do it, it
would make msvcrt.dll setup much less important (and maybe even a way
to keep optional compatibility with older Windows). It seems to me
that llvm-mingw is successful defaulting to UCRT, do you think it
makes sense for upstream default?
Well, that comes with a bit bigger incompatibility, as it breaks most
existing precompiled static libraries.
In a sense, that's not new. We already caused them to be incompatible
many times while changing crt. Of course we try to keep compatibility as
much as possible, but it's often needed if we want to progress. An
example of such changes is moving things to libmsvcrt.a to be able to
better support both ucrt and classic msvcrt.dll. We already did it, so
it's already true that if you mix static libraries with random toolchain
versions, you may run into a problem. I'm not aware of any large scale
practical problems caused by this (but I may be missing something). Of
course a switch to ucrt is an order of magnitude more impactful to
static libraries, but my feeling is that ecosystem can deal with such
changes. I may be too optimistic about this, through.
That's easier for llvm-mingw anyway, as it's mostly incompatible (due
to libc++) - so it's mostly convenient where you build everything from
scratch everytime. But even there, I've now started providing
msvcrt.dll based builds (for people who want to target older versions
where UCRT isn't guaranteed to be available, and for compatibility
with precompiled non-C++ static libraries).
I see, so there is still enough interest in that. It also means that it
would be good to not break it on mingw-w64 crt side. I guess that
keeping msvcrt.dll based crt in its current form is easy. If we want to
use newer features in common (mingwex) code, we can move even more of it
to lib*cr* libraries, keep old behavior in old libraries and use code
depending on newer Windows versions only in ucrt. I can imagine going as
far as moving entire entry point implementations, if it comes to this.
This way old platforms could miss new features, but would not regress.
AFAIK msys2 are considering switching to this as well, but it's in one
sense a much bigger break.
It will be interesting to see how it goes.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
