Re: Windows compile failure for iana time zones

On 1/13/25 05:17, Manuela Friedrich wrote:
It seems that your commit 1ee9daa91818f5d4ab6937352453813fa333e105 fails with: localtime.c(309): error C2099: initializer is not a constant
Thanks for reporting that. Which compiler are you using and what version and what compiler flags are you using? Does the following uninstalled patch fix things for you? If not, what's the value of _MSC_VER when you use your compiler flags? diff --git a/private.h b/private.h index 0a546e02..3e64da4e 100644 --- a/private.h +++ b/private.h @@ -26,7 +26,11 @@ because RHEL 7 (whose GCC defaults to C89) extended life cycle support (ELS) is scheduled to end on 2028-06-30. */ #ifndef PORT_TO_C89 -# define PORT_TO_C89 0 +# if defined _MSC_VER && _MSC_VER < 1800 +# define PORT_TO_C89 1 +# else +# define PORT_TO_C89 0 +# endif #endif /* SUPPORT_C89 means the tzcode library should support C89 callers Perhaps we could use the patch with a different value in place of 1800, or perhaps we should just remove the " && _MSC_VER < 1800". Microsoft says[1] that it didn't add support for C99-style compound literals until Visual Studio 2013. Are you using an older version of MSVC? If so, it's past end-of-life[2] and I doubt whether we should worry about it. [1]: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-stud... [2]: https://devblogs.microsoft.com/visualstudio/support-ends-for-older-versions-...

I am currently using MSVC 6.0, circa 1999, as my primary development IDE/compiler for number of reasons. Its _MSC_VER is 1200: int iWinVer = _MSC_VER; result: iWinVer == 1200; I have not used any earlier Microsoft compilers since 1999. I cannot speak to their _MSC_VER versions. MSVC 6.0 is 32-bit, essentially C99 . The same source will compile in VC 2019 as 64-bit. In my case I have copied and modified zic and relevant portions of glibc code into their own library, that is, I am not attempting to compile the TzDb code directly. I have also created a c++ wrapper class containing those components with their own POSIX environment so that multiple independent instantiations can be created in an application. I would remind that the compiler switches should include both _UNICODE and UNICODE to create a proper Windows executable. Windows has been UNICODE since NT4 and it's important that the CRT compiles as UNICODE.
"Microsoft says[1] that it didn't add support for C99-style compound literals until Visual Studio 2013." I'm not sure when Microsoft came to support compound literals, but with MSVC 6.0 you have to watch out for and work-around that.
I don't know about C89, but I believe you may want to consider support of at least C99. Hope this might help. -Brooks On 2025-01-13 04:32 PM, Paul Eggert via tz wrote:
On 1/13/25 05:17, Manuela Friedrich wrote:
It seems that your commit 1ee9daa91818f5d4ab6937352453813fa333e105 fails with: localtime.c(309): error C2099: initializer is not a constant
Thanks for reporting that. Which compiler are you using and what version and what compiler flags are you using?
Does the following uninstalled patch fix things for you? If not, what's the value of _MSC_VER when you use your compiler flags?
diff --git a/private.h b/private.h index 0a546e02..3e64da4e 100644 --- a/private.h +++ b/private.h @@ -26,7 +26,11 @@ because RHEL 7 (whose GCC defaults to C89) extended life cycle support (ELS) is scheduled to end on 2028-06-30. */ #ifndef PORT_TO_C89 -# define PORT_TO_C89 0 +# if defined _MSC_VER && _MSC_VER < 1800 +# define PORT_TO_C89 1 +# else +# define PORT_TO_C89 0 +# endif #endif
/* SUPPORT_C89 means the tzcode library should support C89 callers
Perhaps we could use the patch with a different value in place of 1800, or perhaps we should just remove the " && _MSC_VER < 1800".
Microsoft says[1] that it didn't add support for C99-style compound literals until Visual Studio 2013. Are you using an older version of MSVC? If so, it's past end-of-life[2] and I doubt whether we should worry about it.
[1]: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-stud... [2]: https://devblogs.microsoft.com/visualstudio/support-ends-for-older-versions-...

On 2025-01-14 06:29, Brooks Harris via tz wrote:
I am currently using MSVC 6.0, circa 1999
OK, but I think Microsoft supports Visual Studio for only ten years and support for MSVC 6.0 ended in 2008[1]. tzcode is intended for current use not computer museums, so typically it shouldn't worry about old, unsupported developer tools. That being said, you're in luck because there is at least one compiler (default GCC on RHEL 7) that is still supported by its supplier and that still doesn't have the C99 features tzcode code uses by default, and because of this until at least July 2028 you should still be able to compile tzcode by using the -DPORT_TO_C89 option, as described in the Makefile and in private.h. So it sounds like we don't need to change tzcode because of this hiccup. [1]: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basi...

On 2025-01-14 03:35 PM, Paul Eggert wrote:
On 2025-01-14 06:29, Brooks Harris via tz wrote:
I am currently using MSVC 6.0, circa 1999
OK, but I think Microsoft supports Visual Studio for only ten years and support for MSVC 6.0 ended in 2008[1]. I'm painfully aware of that. Nonetheless I have it running fine on Windows 11. Why? Because sometimes old stuff is better than new stuff, and in many respects this is. tzcode is intended for current use not computer museums, so typically it shouldn't worry about old, unsupported developer tools.
That being said, you're in luck because there is at least one compiler (default GCC on RHEL 7) that is still supported by its supplier and that still doesn't have the C99 features tzcode code uses by default, and because of this until at least July 2028 you should still be able to compile tzcode by using the -DPORT_TO_C89 option, as described in the Makefile and in private.h. As I said, I'm not trying to do that. I've copied all of zic, zdump, and portions of glibc so as to compile it all directly under MSVC 6.0 and later Microsoft ide/compiiers such as VC 2019. Lots of work, but it builds stable fast Windows executables in 32bit and 64bit.
So it sounds like we don't need to change tzcode because of this hiccup. Probably true. I only sent the info if it helped resolve how you want to go about it.
[1]: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basi... I'm not using Basic, strictly c/c++, but yes, the IDE is no longer supported by them. But it still works good.
Thanks, -Brooks

Further testing showed that recent patch's use of compound literals also runs afoul of GCC in unusual configurations, and it appears that C23 requires that it use 'constexpr' sometimes but not others. So let's drop that and go to the simpler approach that NetBSD uses. This should also work even with no-longer-supported Microsoft compilers. Proposed further patch installed and attached. I hope this is the last thing we need to change before the 2025a release.

Hello Paul, Thanks for the fix. It works well on Windows. We do compile with Visual Studio 2022 ( _MSC_VER = 1934) and Visual Studio 2017 ( _MSC_VER = 1912). Kind Regards Manuela Friedrich On Wed, Jan 15, 2025 at 7:02 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
Further testing showed that recent patch's use of compound literals also runs afoul of GCC in unusual configurations, and it appears that C23 requires that it use 'constexpr' sometimes but not others. So let's drop that and go to the simpler approach that NetBSD uses. This should also work even with no-longer-supported Microsoft compilers. Proposed further patch installed and attached.
I hope this is the last thing we need to change before the 2025a release.
participants (3)
-
Brooks Harris
-
Manuela Friedrich
-
Paul Eggert