From: Eli Zaretskii <eliz@gnu.org>
To: Roger Pack <rogerdpack@gmail.com>
Cc: bruno@clisp.org, bug-gnulib@gnu.org
Subject: Re: gettimeofday.c windows version?
Date: Fri, 23 Dec 2022 10:46:34 +0200 [thread overview]
Message-ID: <83y1qy7bit.fsf@gnu.org> (raw)
In-Reply-To: <CAPfeOnvpX3i0CCgzSEksSrDvcTG5zLHfW55AAWZU4xvtbZoXTw@mail.gmail.com> (message from Roger Pack on Fri, 23 Dec 2022 01:38:01 -0700)
> From: Roger Pack <rogerdpack@gmail.com>
> Date: Fri, 23 Dec 2022 01:38:01 -0700
> Cc: bug-gnulib@gnu.org, Eli Zaretskii <eliz@gnu.org>
>
> OK it appears newer mingw have a default target of windows 10 for some reason. gnutls embedded in this
> case:
> $ x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../.. -U_FORTIFY_SOURCE
> -D_FORTIFY_SOURCE=0 -mtune=generic -O3 -MT gettimeofday.o -MD -MP -MF $depbase.Tpo -c -o - -dM
> -E gettimeofday.c | grep WIN32_WINNT
> #define _WIN32_WINNT 0xa00
> https://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg18212.html
>
> Maybe instead it could always call initialize and "prefer" GetSystemTimePreciseAsFileTime, then be
> compatible with < windows 8 without having to manually set _WIN32_WINNT.
That's what I suggested: to remove the compile-time test, and always
call GetSystemTimePreciseAsFileTime via a function pointer, testing
whether it's supported at run time. I'm not sure Bruno agreed,
though.
> Basically everything using Gnulib gettimeofday + mingw today might "accidentally" lose windows 7 compat
> without realizing it. Though I guess you could call that Mingw's fault, it was a bit confusing.
I guess MinGW64 and MSYS2 are following Cygwin or Microsoft in
dropping old Windows version too quickly. You are welcome to lobby
those two to be less radical, although I'm unsure what are the chances
of that to succeed.
next prev parent reply other threads:[~2022-12-23 8:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 6:01 gettimeofday.c windows version? Roger Pack
2022-12-11 7:05 ` Roger Pack
2022-12-11 14:22 ` Bruno Haible
2022-12-11 15:09 ` Eli Zaretskii
2022-12-11 16:20 ` Bruno Haible
2022-12-11 16:56 ` Eli Zaretskii
2022-12-11 17:25 ` Eli Zaretskii
2022-12-11 18:25 ` Bruno Haible
2022-12-11 18:55 ` Eli Zaretskii
2022-12-12 7:17 ` Paul Eggert
2022-12-12 12:19 ` Bruno Haible
2022-12-12 13:06 ` Eli Zaretskii
2022-12-12 14:25 ` Bruno Haible
2022-12-12 14:40 ` Eli Zaretskii
2022-12-12 19:44 ` Paul Eggert
2022-12-12 20:37 ` Eli Zaretskii
2022-12-16 23:35 ` Paul Eggert
2022-12-17 8:09 ` Eli Zaretskii
2022-12-12 19:14 ` Gisle Vanem
2022-12-23 8:38 ` Roger Pack
2022-12-23 8:46 ` Eli Zaretskii [this message]
2022-12-23 23:47 ` Paul Eggert
2022-12-24 6:46 ` Eli Zaretskii
2022-12-24 7:42 ` Paul Eggert
2022-12-24 8:34 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83y1qy7bit.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=rogerdpack@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).