Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
LGTM.
Thanks for this.
When I originally used ifdef __clang__ we knew it was a hack because we
should be checking the linker and not the compiler but at the time clang
didn’t work well as a drop in replacement for gcc so it was used to specify
one toolchain combination or another.
Glad to see whe have come full circle now.
While linker interop is not possible for short import libs because ld
doesn’t support it, this is a step in the right direction.
On Wed 29 Aug 2018 at 05:09, Martin Storsjö wrote:
> Using the __clang__ ifdef isn't right; one could be using clang for
> compiling the mingw-w64 crt for use with binutils ld, which requires
> a slightly different setup of __CTOR_LIST__.
>
> Also, to ease interoperability between binutils ld and lld, lld could
> potentially start providing the __CTOR_LIST__ symbol, and in that case
> we shouldn't be providing it ourselves either.
>
> Signed-off-by: Martin Storsjö
> ---
> This time by setting ac_no_link=no temporarily at the same time as we are
> adding -nostdlib to LDFLAGS, to allow running the linker test even though
> target libraries aren't necessarily available yet.
> ---
> mingw-w64-crt/configure.ac | 48
> +
> mingw-w64-crt/crt/crtdll.c | 6 +-
> mingw-w64-crt/crt/crtexe.c | 6 +-
> mingw-w64-crt/crt/gccmain.c | 8 +++-
> 4 files changed, 65 insertions(+), 3 deletions(-)
>
> diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
> index 6a42109..a492c1b 100644
> --- a/mingw-w64-crt/configure.ac
> +++ b/mingw-w64-crt/configure.ac
> @@ -301,6 +301,54 @@ AC_ARG_ENABLE([tests-unicode],
> AM_CONDITIONAL([ENABLE_TESTS_UNICODE],[test x$enable_tests_unicode =
> xyes])
> AC_MSG_RESULT([$enable_tests_unicode])
>
> +AC_MSG_CHECKING([whether the linker provides __CTOR_LIST__])
> +saved_LDFLAGS="$LDFLAGS"
> +saved_ac_no_link="$ac_no_link"
> +LDFLAGS="$LDFLAGS -nostdlib"
> +# Force ac_no_link to "no". When bootstrapping an environment, autoconf
> will
> +# earlier conclude that linking isn't possible (since -lmingw32 etc are
> +# missing), and set ac_no_link=yes. This forbids us from doing a test with
> +# AC_LINK_IFELSE here, even though we are knowingly setting -nostdlib, to
> +# make this specific testcase work even though the normally linked
> libraries
> +# aren't available yet. Override this variable to allow us to perform the
> link
> +# test.
> +ac_no_link=no
> +# Note that binutils 2.30 is broken with respect to __CTOR_LIST__ (the
> change
> +# was reverted for 2.31); it does provide __CTOR_LIST__ automatically
> only if
> +# necessary. But as long as there's no other definition of it, a fallback
> +# __CTOR_LIST__ gets pulled in from libgcc, and this fallback is only a
> dummy
> +# to prevent linker errors (in general) and isn't assigned to the right
> +# sections. Therefore, it'd be better to test whether we can/should
> provide
> +# our own __CTOR_LIST__.
> +
> +# But we can't test whether we can provide our own __CTOR_LIST__ with
> binutils
> +# ld either; even if our test provides its own symbol __CTOR_LIST__, ld
> will
> +# include it but silently use its own provided __CTOR_LIST__ instead, and
> +# won't error out. For actual real use, that'd mean a stray broken
> pointer in
> +# the .ctors section.
> +
> +# This test uses both mainCRTStartup and main functions, to let lld deduce
> +# entry point and subsystem automatically without having to manually
> specify,
> +# anything. And as long as main() is provided, we need to implicitly
> provide
> +# __main as well, since the compiler injects a call to it.
> +AC_LINK_IFELSE([AC_LANG_SOURCE([[
> +#include
> +extern const void * __CTOR_LIST__;
> +void __main(void) {
> +}
> +int main(void) {
> + return (int)(intptr_t)__CTOR_LIST__;
> +}
> +int mainCRTStartup(void) {
> + return main();
> +}
> +]])],
> +[AC_DEFINE([HAVE_CTOR_LIST],[1],[Whether the linker provides
> __CTOR_LIST__])
> +AC_MSG_RESULT(yes)],
> +[AC_MSG_RESULT(no)])
> +LDFLAGS="$saved_LDFLAGS"
> +ac_no_link="$saved_ac_no_link"
> +
> # Checks for libraries.
>
> # Checks for header files.
> diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
> index 5f53602..6187f10 100644
> --- a/mingw-w64-crt/crt/crtdll.c
> +++ b/mingw-w64-crt/crt/crtdll.c
> @@ -10,6 +10,10 @@
> #define _DLL
> #endif
>
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> #include
> #include
> #include
> @@ -40,7 +44,7 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
> extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
> extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
>
> -#ifdef __clang__
> +#ifndef HAVE_CTOR_LIST
> __attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void
> * const void * __CTOR_LIST__ = (void *) -1;
> __attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void
> * const void * __DTOR_LIST__ = (void *) -1;
> __attribute__ (( __section__ (".ctors.9"), __used__ ,
> aligned(sizeof(void * const void * __CTOR
Re: [Mingw-w64-public] Error with evntrace.h
The struct `WNODE_HEADER` and the enumeration `WMIDPREQUESTCODE` are defined in ``wmistr.h'' file. File ``evntrace.h'' includes ``wmistr.h'' one using the following define-guard: mingw-w64: ``` #ifndef _EVNTRACE_KERNEL_MODE #include #endif ``` Microsoft Windows 10.0.17134 SDK: ``` #if !defined(_EVNTRACE_KERNEL_MODE) #include #endif ``` Therefore, to compile your code successfully you must have `_EVNTRACE_KERNEL_MODE` defined I believe. On 8/29/2018 12:36 PM, Biswapriyo Nath wrote: When I include `evntrace.h` gcc shows these errors: ``` In file included from TraceEvent.h:10:0, from main.h:4, from main.c:1: e:\mingw64\x86_64-w64-mingw32\include\evntrace.h:513:3: error: unknown type name 'WNODE_HEADER' WNODE_HEADER Wnode; ^ e:\mingw64\x86_64-w64-mingw32\include\evntrace.h:608:38: error: unknown type name 'WMIDPREQUESTCODE' typedef ULONG (WINAPI *WMIDPREQUEST)(WMIDPREQUESTCODE RequestCode,PVOID RequestContext,ULONG *BufferSize,PVOID Buffer); ^ In file included from TraceEvent.h:10:0, from main.h:4, from main.c:1: e:\mingw64\x86_64-w64-mingw32\include\evntrace.h:767:43: error: unknown type name 'WMIDPREQUEST' EXTERN_C ULONG WMIAPI RegisterTraceGuidsW(WMIDPREQUEST RequestAddress,PVOID RequestContext,LPCGUID ControlGuid,ULONG GuidCount,PTRACE_GUID_REGISTRATION TraceGuidReg,LPCWSTR MofImagePath,LPCWSTR MofResourceName,PTRACEHANDLE RegistrationHandle); ^ e:\mingw64\x86_64-w64-mingw32\include\evntrace.h:768:43: error: unknown type name 'WMIDPREQUEST' EXTERN_C ULONG WMIAPI RegisterTraceGuidsA(WMIDPREQUEST RequestAddress,PVOID RequestContext,LPCGUID ControlGuid,ULONG GuidCount,PTRACE_GUID_REGISTRATION TraceGuidReg,LPCSTR MofImagePath,LPCSTR MofResourceName,PTRACEHANDLE RegistrationHandle); ^ ``` May be there are some errors in the evntrace.h file. Or am I doing anything wrong? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
Using the __clang__ ifdef isn't right; one could be using clang for
compiling the mingw-w64 crt for use with binutils ld, which requires
a slightly different setup of __CTOR_LIST__.
Also, to ease interoperability between binutils ld and lld, lld could
potentially start providing the __CTOR_LIST__ symbol, and in that case
we shouldn't be providing it ourselves either.
Signed-off-by: Martin Storsjö
---
This time by setting ac_no_link=no temporarily at the same time as we are
adding -nostdlib to LDFLAGS, to allow running the linker test even though
target libraries aren't necessarily available yet.
---
mingw-w64-crt/configure.ac | 48 +
mingw-w64-crt/crt/crtdll.c | 6 +-
mingw-w64-crt/crt/crtexe.c | 6 +-
mingw-w64-crt/crt/gccmain.c | 8 +++-
4 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
index 6a42109..a492c1b 100644
--- a/mingw-w64-crt/configure.ac
+++ b/mingw-w64-crt/configure.ac
@@ -301,6 +301,54 @@ AC_ARG_ENABLE([tests-unicode],
AM_CONDITIONAL([ENABLE_TESTS_UNICODE],[test x$enable_tests_unicode = xyes])
AC_MSG_RESULT([$enable_tests_unicode])
+AC_MSG_CHECKING([whether the linker provides __CTOR_LIST__])
+saved_LDFLAGS="$LDFLAGS"
+saved_ac_no_link="$ac_no_link"
+LDFLAGS="$LDFLAGS -nostdlib"
+# Force ac_no_link to "no". When bootstrapping an environment, autoconf will
+# earlier conclude that linking isn't possible (since -lmingw32 etc are
+# missing), and set ac_no_link=yes. This forbids us from doing a test with
+# AC_LINK_IFELSE here, even though we are knowingly setting -nostdlib, to
+# make this specific testcase work even though the normally linked libraries
+# aren't available yet. Override this variable to allow us to perform the link
+# test.
+ac_no_link=no
+# Note that binutils 2.30 is broken with respect to __CTOR_LIST__ (the change
+# was reverted for 2.31); it does provide __CTOR_LIST__ automatically only if
+# necessary. But as long as there's no other definition of it, a fallback
+# __CTOR_LIST__ gets pulled in from libgcc, and this fallback is only a dummy
+# to prevent linker errors (in general) and isn't assigned to the right
+# sections. Therefore, it'd be better to test whether we can/should provide
+# our own __CTOR_LIST__.
+
+# But we can't test whether we can provide our own __CTOR_LIST__ with binutils
+# ld either; even if our test provides its own symbol __CTOR_LIST__, ld will
+# include it but silently use its own provided __CTOR_LIST__ instead, and
+# won't error out. For actual real use, that'd mean a stray broken pointer in
+# the .ctors section.
+
+# This test uses both mainCRTStartup and main functions, to let lld deduce
+# entry point and subsystem automatically without having to manually specify,
+# anything. And as long as main() is provided, we need to implicitly provide
+# __main as well, since the compiler injects a call to it.
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
+#include
+extern const void * __CTOR_LIST__;
+void __main(void) {
+}
+int main(void) {
+ return (int)(intptr_t)__CTOR_LIST__;
+}
+int mainCRTStartup(void) {
+ return main();
+}
+]])],
+[AC_DEFINE([HAVE_CTOR_LIST],[1],[Whether the linker provides __CTOR_LIST__])
+AC_MSG_RESULT(yes)],
+[AC_MSG_RESULT(no)])
+LDFLAGS="$saved_LDFLAGS"
+ac_no_link="$saved_ac_no_link"
+
# Checks for libraries.
# Checks for header files.
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 5f53602..6187f10 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -10,6 +10,10 @@
#define _DLL
#endif
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#include
#include
#include
@@ -40,7 +44,7 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
-#ifdef __clang__
+#ifndef HAVE_CTOR_LIST
__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *
const void * __CTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *
const void * __DTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".ctors.9"), __used__ , aligned(sizeof(void
* const void * __CTOR_END__ = (void *) 0;
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index 80e0556..361afd2 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -9,6 +9,10 @@
#define _DLL
#endif
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#define SPECIAL_CRTEXE
#include
@@ -64,7 +68,7 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
-#ifdef __clang__
+#ifndef HAVE_CTOR_LIST
__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *
const void * __CTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *
const void * __DTOR_LI
Re: [Mingw-w64-public] #define daylight causes conflicts
Hi,
> On Aug 29, 2018, at 12:02, Jacek Caban wrote:
>
> On 29/08/2018 09:59, Martin Storsjö wrote:
>>> On Aug 29, 2018, at 10:15, Jacek Caban wrote:
>>>
>>> On 29/08/2018 08:20, Martin Storsjö wrote:
>>>
> On Aug 29, 2018, at 05:27, Liu Hao wrote:
>
> 在 2018/8/29 4:36, Tom Ritter 写道:
>> I hit this issue compiling ICU as part of Firefox, where they had a
>> variable named 'daylight'.
>> https://unicode-org.atlassian.net/browse/ICU-20100 was filed to change
>> the variable name; but I wanted to bring it up since these types of
>> defines are inevitably cause more breakage in the future...
>> I have no idea about what issue this was put in to address, nor any
>> opinions about how to fix it, I merely wanted to raise the concern
>> since it tripped us up.
> Probably the macro `daylight` should be removed.
Yes, ideally - suggestions are welcome.
>>> MSVC doesn't support 'daylight' symbol in recent version. Ideally we'd do
>>> the same and just remove the macro. Do you have a sense about how bad that
>>> would be for existing applications?
>> I'm not sure if specifically daylight is necessary anywhere,
>
> Maybe we could remove it and revisit if it causes too much damage.
>
>> but at least "timezone", which also isn't exposed by MSVC, would break Qt if
>> we were to remove it. Qt has got a wrapper that looks like this:
>>
>> static int qt_timezone() {
>> #if defined(_MSC_VER)
>> long offset;
>> _get_timezone(&offset);
>> return offset;
>> #elif defined(Q_OS_BSD4) && !defined(Q_OS_DARWIN)
>> [...]
>> #elif defined(Q_OS_INTEGRITY)
>> return 0;
>> #else
>> return timezone;
>> #endif
>> }
>>
>
> I'd say that Qt should check for _WIN32 instead of _MSC_VER here and use
> _get_timezone in mingw builds. It would then work the way it's intended to be
> done on Windows. We even have a warning attribute suggesting that.
Well, the issue is that _get_timezone only exists in msvcrXXX.dll and ucrt, but
not for the plain msvcrt.dll. We could of course add a compat wrapper for that,
but if we make Qt use that, then Qt suddenly requires the very latest
unreleased version of mingw-w64. (They do generally require a rather new
version though.)
If we’d just make them use _timezone instead of timezone for windows in general
(or at least as a separate step after _MSC_VER), it should be good to go
already without requiring the very latest mingw-w64.
And FWIW, the warning attribute has only been there since we started sorting
out these timezone global variables for ucrt last year.
> Patches that you sent are an improvement over current solution, so I'm fine
> with taking them. They look good to me, thanks.
Thanks, will push them in a little while then.
> I'd still prefer to just drop those symbols. MS did that, having much bigger
> user base, and people adopted. We're targeting MS crt, which doesn't have
> clear backward compatibility support, so it seems reasonable to follow their
> changes. Expecting developers to make small changes when porting to new crt
> (ucrt in this case) is also not unreasonable. That said, I'd prefer dropping,
> but I'm not sure we should do that. I don't have enough information to
> estimate the damage it would cause.
That’s probably the nicest way forward, but then we should at least first fix
Qt so that it doesn’t break once we do that.
// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] #define daylight causes conflicts
Hi Martin,
On 29/08/2018 09:59, Martin Storsjö wrote:
On Aug 29, 2018, at 10:15, Jacek Caban wrote:
On 29/08/2018 08:20, Martin Storsjö wrote:
On Aug 29, 2018, at 05:27, Liu Hao wrote:
在 2018/8/29 4:36, Tom Ritter 写道:
I hit this issue compiling ICU as part of Firefox, where they had a
variable named 'daylight'.
https://unicode-org.atlassian.net/browse/ICU-20100 was filed to change
the variable name; but I wanted to bring it up since these types of
defines are inevitably cause more breakage in the future...
I have no idea about what issue this was put in to address, nor any
opinions about how to fix it, I merely wanted to raise the concern
since it tripped us up.
Probably the macro `daylight` should be removed.
Yes, ideally - suggestions are welcome.
MSVC doesn't support 'daylight' symbol in recent version. Ideally we'd do the
same and just remove the macro. Do you have a sense about how bad that would be
for existing applications?
I'm not sure if specifically daylight is necessary anywhere,
Maybe we could remove it and revisit if it causes too much damage.
but at least "timezone", which also isn't exposed by MSVC, would break Qt if
we were to remove it. Qt has got a wrapper that looks like this:
static int qt_timezone() {
#if defined(_MSC_VER)
long offset;
_get_timezone(&offset);
return offset;
#elif defined(Q_OS_BSD4) && !defined(Q_OS_DARWIN)
[...]
#elif defined(Q_OS_INTEGRITY)
return 0;
#else
return timezone;
#endif
}
I'd say that Qt should check for _WIN32 instead of _MSC_VER here and use
_get_timezone in mingw builds. It would then work the way it's intended
to be done on Windows. We even have a warning attribute suggesting that.
Patches that you sent are an improvement over current solution, so I'm
fine with taking them. They look good to me, thanks.
I'd still prefer to just drop those symbols. MS did that, having much
bigger user base, and people adopted. We're targeting MS crt, which
doesn't have clear backward compatibility support, so it seems
reasonable to follow their changes. Expecting developers to make small
changes when porting to new crt (ucrt in this case) is also not
unreasonable. That said, I'd prefer dropping, but I'm not sure we should
do that. I don't have enough information to estimate the damage it would
cause.
Thanks,
Jacek
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/2] ucrt: Don't define daylight as a macro in the header
Instead expose a fake __imp_daylight in ucrtbase_compat.c which
initially has the same value as (*__daylight()) from ucrtbase.dll,
and after calling _tzset, redirect __imp_daylight to the ucrtbase.dll
provided value.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/crt/ucrtbase_compat.c | 3 +++
mingw-w64-headers/crt/time.h| 3 +--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/crt/ucrtbase_compat.c
b/mingw-w64-crt/crt/ucrtbase_compat.c
index f7e41e0..4c71d26 100644
--- a/mingw-w64-crt/crt/ucrtbase_compat.c
+++ b/mingw-w64-crt/crt/ucrtbase_compat.c
@@ -119,8 +119,10 @@ static char initial_tzname0[] = "PST";
static char initial_tzname1[] = "PDT";
static char *initial_tznames[] = { initial_tzname0, initial_tzname1 };
static long initial_timezone = 28800;
+static int initial_daylight = 1;
char** __MINGW_IMP_SYMBOL(tzname) = initial_tznames;
long * __MINGW_IMP_SYMBOL(timezone) = &initial_timezone;
+int * __MINGW_IMP_SYMBOL(daylight) = &initial_daylight;
void __cdecl _tzset(void)
{
@@ -129,6 +131,7 @@ void __cdecl _tzset(void)
// From this point, the exposed values should stay in sync.
__MINGW_IMP_SYMBOL(tzname) = _tzname;
__MINGW_IMP_SYMBOL(timezone) = __timezone();
+ __MINGW_IMP_SYMBOL(daylight) = __daylight();
}
void __cdecl tzset(void)
diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
index 886ec94..73f6264 100644
--- a/mingw-w64-headers/crt/time.h
+++ b/mingw-w64-headers/crt/time.h
@@ -272,12 +272,11 @@ __forceinline errno_t __cdecl ctime_s(char *_Buf,size_t
_SizeInBytes,const time_
__MINGW_ATTRIB_DEPRECATED_MSG( \
"Only provided for source compatibility; this variable might " \
"not always be accurate when linking to ucrtbase.dll.")
-#define daylight (_daylight)
#else
#define __MINGW_ATTRIB_DEPRECATED_UCRT
- _CRTIMP extern int daylight;
#endif
+ _CRTIMP extern int daylight __MINGW_ATTRIB_DEPRECATED_UCRT;
_CRTIMP extern long timezone __MINGW_ATTRIB_DEPRECATED_UCRT;
_CRTIMP extern char *tzname[2] __MINGW_ATTRIB_DEPRECATED_UCRT;
void __cdecl tzset(void) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
--
2.7.4
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 1/2] ucrt: Improve handling of timezone and tzname
Redirect __imp_timezone to the ucrt one, after _tzset is called. This keeps
the returned value in sync even if a different module calls _tzset again.
Also initialize the local values to the same ones as msvcrt.dll/ucrtbase.dll
exposes before _tzset has been called.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/crt/ucrtbase_compat.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-crt/crt/ucrtbase_compat.c
b/mingw-w64-crt/crt/ucrtbase_compat.c
index fcdc8ca..f7e41e0 100644
--- a/mingw-w64-crt/crt/ucrtbase_compat.c
+++ b/mingw-w64-crt/crt/ucrtbase_compat.c
@@ -113,15 +113,22 @@ wchar_t *** __MINGW_IMP_SYMBOL(__winitenv) =
&local__winitenv;
typedef void __cdecl (*_tzset_func)(void);
extern _tzset_func __MINGW_IMP_SYMBOL(_tzset);
-static long local_timezone;
-char** __MINGW_IMP_SYMBOL(tzname);
-long * __MINGW_IMP_SYMBOL(timezone) = &local_timezone;
+// Default initial values until _tzset has been called; these are the same
+// as the initial values in msvcrt/ucrtbase.
+static char initial_tzname0[] = "PST";
+static char initial_tzname1[] = "PDT";
+static char *initial_tznames[] = { initial_tzname0, initial_tzname1 };
+static long initial_timezone = 28800;
+char** __MINGW_IMP_SYMBOL(tzname) = initial_tznames;
+long * __MINGW_IMP_SYMBOL(timezone) = &initial_timezone;
void __cdecl _tzset(void)
{
__MINGW_IMP_SYMBOL(_tzset)();
+ // Redirect the __imp_ pointers to the actual data provided by the UCRT.
+ // From this point, the exposed values should stay in sync.
__MINGW_IMP_SYMBOL(tzname) = _tzname;
- local_timezone = _timezone;
+ __MINGW_IMP_SYMBOL(timezone) = __timezone();
}
void __cdecl tzset(void)
--
2.7.4
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] #define daylight causes conflicts
> On Aug 29, 2018, at 10:15, Jacek Caban wrote:
>
> On 29/08/2018 08:20, Martin Storsjö wrote:
>
>>> On Aug 29, 2018, at 05:27, Liu Hao wrote:
>>>
>>> 在 2018/8/29 4:36, Tom Ritter 写道:
I hit this issue compiling ICU as part of Firefox, where they had a
variable named 'daylight'.
https://unicode-org.atlassian.net/browse/ICU-20100 was filed to change
the variable name; but I wanted to bring it up since these types of
defines are inevitably cause more breakage in the future...
I have no idea about what issue this was put in to address, nor any
opinions about how to fix it, I merely wanted to raise the concern
since it tripped us up.
>>> Probably the macro `daylight` should be removed.
>> Yes, ideally - suggestions are welcome.
>>
>
> MSVC doesn't support 'daylight' symbol in recent version. Ideally we'd do the
> same and just remove the macro. Do you have a sense about how bad that would
> be for existing applications?
I'm not sure if specifically daylight is necessary anywhere, but at least
"timezone", which also isn't exposed by MSVC, would break Qt if we were to
remove it. Qt has got a wrapper that looks like this:
static int qt_timezone() {
#if defined(_MSC_VER)
long offset;
_get_timezone(&offset);
return offset;
#elif defined(Q_OS_BSD4) && !defined(Q_OS_DARWIN)
[...]
#elif defined(Q_OS_INTEGRITY)
return 0;
#else
return timezone;
#endif
}
// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Error with evntrace.h
When I include `evntrace.h` gcc shows these errors: ``` In file included from TraceEvent.h:10:0, from main.h:4, from main.c:1: e:\mingw64\x86_64-w64-mingw32\include\evntrace.h:513:3: error: unknown type name 'WNODE_HEADER' WNODE_HEADER Wnode; ^ e:\mingw64\x86_64-w64-mingw32\include\evntrace.h:608:38: error: unknown type name 'WMIDPREQUESTCODE' typedef ULONG (WINAPI *WMIDPREQUEST)(WMIDPREQUESTCODE RequestCode,PVOID RequestContext,ULONG *BufferSize,PVOID Buffer); ^ In file included from TraceEvent.h:10:0, from main.h:4, from main.c:1: e:\mingw64\x86_64-w64-mingw32\include\evntrace.h:767:43: error: unknown type name 'WMIDPREQUEST' EXTERN_C ULONG WMIAPI RegisterTraceGuidsW(WMIDPREQUEST RequestAddress,PVOID RequestContext,LPCGUID ControlGuid,ULONG GuidCount,PTRACE_GUID_REGISTRATION TraceGuidReg,LPCWSTR MofImagePath,LPCWSTR MofResourceName,PTRACEHANDLE RegistrationHandle); ^ e:\mingw64\x86_64-w64-mingw32\include\evntrace.h:768:43: error: unknown type name 'WMIDPREQUEST' EXTERN_C ULONG WMIAPI RegisterTraceGuidsA(WMIDPREQUEST RequestAddress,PVOID RequestContext,LPCGUID ControlGuid,ULONG GuidCount,PTRACE_GUID_REGISTRATION TraceGuidReg,LPCSTR MofImagePath,LPCSTR MofResourceName,PTRACEHANDLE RegistrationHandle); ^ ``` May be there are some errors in the evntrace.h file. Or am I doing anything wrong? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] #define daylight causes conflicts
On 29/08/2018 08:20, Martin Storsjö wrote: On Aug 29, 2018, at 05:27, Liu Hao wrote: 在 2018/8/29 4:36, Tom Ritter 写道: I hit this issue compiling ICU as part of Firefox, where they had a variable named 'daylight'. https://unicode-org.atlassian.net/browse/ICU-20100 was filed to change the variable name; but I wanted to bring it up since these types of defines are inevitably cause more breakage in the future... I have no idea about what issue this was put in to address, nor any opinions about how to fix it, I merely wanted to raise the concern since it tripped us up. Probably the macro `daylight` should be removed. Yes, ideally - suggestions are welcome. MSVC doesn't support 'daylight' symbol in recent version. Ideally we'd do the same and just remove the macro. Do you have a sense about how bad that would be for existing applications? Jacek -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
