Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

2019-11-21 Thread Bernhard Übelacker 
Am 21.11.19 um 16:13 schrieb Marius Mikučionis:
> 2019-11-21, th, 13:14 Bernhard Übelacker  > wrote:
> 
> 
> I forgot to mention that I used a local built wine-4.20.
> There were lately some changes in that area in Wine, therefore
> if you use an older Wine version it might behave different.
> 
>     https://source.winehq.org/git/wine.git/history/HEAD:/dlls/msvcrt
> 
> 
> OK.
>  
> 
> But does the executable with -lucrt print the expected
> output in Windows?
> 
> 
> Interesting: in windows with -lucrt prints correctly, but not in wine-4.0.2.
> I see that Debian has wine64-development-4.19 and 4.20, I will test those.
> 
> Summary for %e:
>            | no -lucrt  | with -lucrt
> windows    | fail       | pass
> wine-4.0.2 | fail       | fail
> wine-4.19  | fail       | pass
> wine-4.20  | fail*      | pass
> 
> Summary for %z:
>            | no -lucrt  | with -lucrt
> windows    | fail       | pass
> wine-4.0.2 | fail       | fail
> wine-4.19  | fail       | fail
> wine-4.20  | fail       | pass
> 
> * wine-4.20 also prints extra debug information for %e without -lucrt:
> 0009:err:msvcrt:MSVCRT__invalid_parameter (null):0 (null): (null) 0
> 
> Looks like the issue is with the runtime environment and not with mingw.
> I still would like to understand if/why -lucrt is necessary in this case.
> The documentation does not mention any libraries, only headers.
>  
> 
> >     At least the binaries produced in my tests behave the same
> >     in Wine and Windows.
> >
> > Even without -lucrt ?
> > The ucrt adds those api-ms-win-crt-* dependencies, which do not
> seem to
> > be necessary.
> 
> Looking at the complete output of i686-w64-mingw32-objdump shows that
> without -lucrt strftime is imported from msvcrt.dll.
> With -lucrt it imports strftime from api-ms-win-crt-time-l1-1-0.dll.
> That is what I guess makes the difference.
> 
> 
> Does that mean that strftime implementation in msvcrt.dll is faulty?
> 

>From my point of view, Microsoft cannot change msvcrt.dll because plenty
legacy software may rely on the "old" behaviour.
Therefore we got then msvcr90.dll and so on. And now they invented UCRT.
As Stephen wrote in message 20, if you compile with visual studio the
binary will link also against these UCRT libraries.

And documentation seems just to cover supported development
environments...

> -- 
> Marius

Kind regards,
Bernhard

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

2019-11-21 Thread Marius Mikučionis 
2019-11-21, th, 13:14 Bernhard Übelacker  wrote:

>
> I forgot to mention that I used a local built wine-4.20.
> There were lately some changes in that area in Wine, therefore
> if you use an older Wine version it might behave different.
>
> https://source.winehq.org/git/wine.git/history/HEAD:/dlls/msvcrt
>

OK.


> But does the executable with -lucrt print the expected
> output in Windows?
>

Interesting: in windows with -lucrt prints correctly, but not in wine-4.0.2.
I see that Debian has wine64-development-4.19 and 4.20, I will test those.

Summary for %e:
   | no -lucrt  | with -lucrt
windows| fail   | pass
wine-4.0.2 | fail   | fail
wine-4.19  | fail   | pass
wine-4.20  | fail*  | pass

Summary for %z:
   | no -lucrt  | with -lucrt
windows| fail   | pass
wine-4.0.2 | fail   | fail
wine-4.19  | fail   | fail
wine-4.20  | fail   | pass

* wine-4.20 also prints extra debug information for %e without -lucrt:
0009:err:msvcrt:MSVCRT__invalid_parameter (null):0 (null): (null) 0

Looks like the issue is with the runtime environment and not with mingw.
I still would like to understand if/why -lucrt is necessary in this case.
The documentation does not mention any libraries, only headers.


> > At least the binaries produced in my tests behave the same
> > in Wine and Windows.
> >
> > Even without -lucrt ?
> > The ucrt adds those api-ms-win-crt-* dependencies, which do not seem to
> > be necessary.
>
> Looking at the complete output of i686-w64-mingw32-objdump shows that
> without -lucrt strftime is imported from msvcrt.dll.
> With -lucrt it imports strftime from api-ms-win-crt-time-l1-1-0.dll.
> That is what I guess makes the difference.
>

Does that mean that strftime implementation in msvcrt.dll is faulty?

-- 
Marius

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

2019-11-21 Thread Bernhard Übelacker 


Am 21.11.19 um 12:09 schrieb Marius Mikučionis:
> 
> 2019-11-21, kt, 01:16 Bernhard Übelacker  > rašė:

>     $ wine strftime-ucrt-7.exe
>     [%a]: [Tue]
>     [%e]: [ 5]
>     [%d]: [05]
>     [%-d]: (empty) errno=22
>     [%#d]: [5]
>     [%b]: [Nov]
>     [%Y]: [2019]
>     [%H]: [03]
>     [%M]: [02]
>     [%S]: [01]
>     [%z]: [+0100]
>     [%Z]: [Mitteleuropõische Zeit]
>     [%b%e, %Y, %H:%M:%S %z]: [Nov 5, 2019, 03:02:01 +0100]
> 
> (msvcrt.dll still appears; the same result for 7.0.0-2 and 6.0.0-3.)
> 
> Your output is correct, but I am not getting that, very strange.
> 

I forgot to mention that I used a local built wine-4.20.
There were lately some changes in that area in Wine, therefore
if you use an older Wine version it might behave different.

https://source.winehq.org/git/wine.git/history/HEAD:/dlls/msvcrt

But does the executable with -lucrt print the expected
output in Windows?


> At least the binaries produced in my tests behave the same
> in Wine and Windows.
> 
> Even without -lucrt ?
> The ucrt adds those api-ms-win-crt-* dependencies, which do not seem to
> be necessary.

Looking at the complete output of i686-w64-mingw32-objdump shows that
without -lucrt strftime is imported from msvcrt.dll.
With -lucrt it imports strftime from api-ms-win-crt-time-l1-1-0.dll.
That is what I guess makes the difference.

> Thank you for the effort, perhaps something strange is happening with my
> setup, I could not find anyone else on internet with this issue.
> 
> -- 
> Marius

Kind regards,
Bernhard

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

2019-11-21 Thread Stephen Kitt 
Hi,

Thanks to both of you for taking the time to file the bug and investigate
this!

On Thu, 21 Nov 2019 12:09:44 +0100, Marius Mikučionis 
wrote:
> 2019-11-21, kt, 01:16 Bernhard Übelacker  rašė:
> > First I fear that mingw-w64 does not link as much static
> > as you expect it to.

Yes, strftime and most other C library functions are implemented in the
underlying CRT, not MinGW-w64.

> > And the Microsoft page might just be right for later versions
> > of c runtimes they provide.

I think so too; there’s a drop-down to select different versions of Visual
Studio, but all the versions for which documentation is currently provided
use UCRT.

> > Further I found this information [2], which is as far as
> > I understand about recompiling mingw.
> > But I tried just to modify the compile/link command,
> > which I guess is kind of the expected output?
> >
> > $ i686-w64-mingw32-gcc -static -O3 -Wall -o strftime-ucrt-7.exe
> > strftime.c -lucrt
> > $ i686-w64-mingw32-objdump -p strftime-ucrt-7.exe | grep 'DLL Name:'
> > DLL Name: KERNEL32.dll
> > DLL Name: msvcrt.dll
> > DLL Name: api-ms-win-crt-environment-l1-1-0.dll
> > DLL Name: api-ms-win-crt-heap-l1-1-0.dll
> > DLL Name: api-ms-win-crt-private-l1-1-0.dll
> > DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
> > DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
> > DLL Name: api-ms-win-crt-string-l1-1-0.dll
> > DLL Name: api-ms-win-crt-time-l1-1-0.dll
> 
> I can reproduce this too.

Yes, this is normal. Doing a proper link with UCRT requires at minimum
overriding the GCC spec file, as described in
https://sourceforge.net/p/mingw-w64/mailman/message/36621319/

> > $ wine strftime-ucrt-7.exe
> > [%a]: [Tue]
> > [%e]: [ 5]
> > [%d]: [05]
> > [%-d]: (empty) errno=22
> > [%#d]: [5]
> > [%b]: [Nov]
> > [%Y]: [2019]
> > [%H]: [03]
> > [%M]: [02]
> > [%S]: [01]
> > [%z]: [+0100]
> > [%Z]: [Mitteleuropõische Zeit]
> > [%b%e, %Y, %H:%M:%S %z]: [Nov 5, 2019, 03:02:01 +0100]
> >
> > (msvcrt.dll still appears; the same result for 7.0.0-2 and 6.0.0-3.)
> 
> Your output is correct, but I am not getting that, very strange.

I’m guessing this works for Bernhard because he’s using a newer version of
Wine than either Marius or myself; %e was implemented in 4.18, for _MSVCR_VER
140 or later, and %z in 4.20.

> > At least the binaries produced in my tests behave the same
> > in Wine and Windows.
> 
> Even without -lucrt ?
> The ucrt adds those api-ms-win-crt-* dependencies, which do not seem to be
> necessary.

They’re all part of the UCRT interface; you’ll get the same dependencies with
Visual Studio.

> Thank you for the effort, perhaps something strange is happening with my
> setup, I could not find anyone else on internet with this issue.

There’s nothing strange in your setup!

I’m wondering what the appropriate solution is. Strictly speaking, this isn’t
a bug in MinGW-w64, and using the default MSVCRT target there’s nothing much
we can do. However it does raise the question of UCRT support in Debian...

Regards,

Stephen


pgpEf7xwAAb9H.pgp
Description: OpenPGP digital signature

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

2019-11-21 Thread Marius Mikučionis 
2019-11-21, kt, 01:16 Bernhard Übelacker  rašė:

> Hello Marius Mikucionis,
> I am not anyhow involved in maintaining mingw-w64.
> But I guess I found something.
>
> First I fear that mingw-w64 does not link as much static
> as you expect it to.
> All crossbuilt executables still dynamically link to msvcrt.dll.
>
> $ i686-w64-mingw32-objdump -p strftime-6.exe | grep 'DLL Name:'
> DLL Name: KERNEL32.dll
> DLL Name: msvcrt.dll
>

Interesting. I get exactly the same.



> And the Microsoft page might just be right for later versions
> of c runtimes they provide.
>
> Further I found this information [2], which is as far as
> I understand about recompiling mingw.
> But I tried just to modify the compile/link command,
> which I guess is kind of the expected output?
>
> $ i686-w64-mingw32-gcc -static -O3 -Wall -o strftime-ucrt-7.exe
> strftime.c -lucrt
> $ i686-w64-mingw32-objdump -p strftime-ucrt-7.exe | grep 'DLL Name:'
> DLL Name: KERNEL32.dll
> DLL Name: msvcrt.dll
> DLL Name: api-ms-win-crt-environment-l1-1-0.dll
> DLL Name: api-ms-win-crt-heap-l1-1-0.dll
> DLL Name: api-ms-win-crt-private-l1-1-0.dll
> DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
> DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
> DLL Name: api-ms-win-crt-string-l1-1-0.dll
> DLL Name: api-ms-win-crt-time-l1-1-0.dll
>

I can reproduce this too.


>
> $ wine strftime-ucrt-7.exe
> [%a]: [Tue]
> [%e]: [ 5]
> [%d]: [05]
> [%-d]: (empty) errno=22
> [%#d]: [5]
> [%b]: [Nov]
> [%Y]: [2019]
> [%H]: [03]
> [%M]: [02]
> [%S]: [01]
> [%z]: [+0100]
> [%Z]: [Mitteleuropõische Zeit]
> [%b%e, %Y, %H:%M:%S %z]: [Nov 5, 2019, 03:02:01 +0100]
>
> (msvcrt.dll still appears; the same result for 7.0.0-2 and 6.0.0-3.)
>

Your output is correct, but I am not getting that, very strange.



> So maybe you could examine this binaries from 2014 if they
> need also some Dlls?
>

Yes, they have those dependencies and more (like WS2_32.DLL and
IPHLPAPI.DLL, but they are unrelated).



>
> At least the binaries produced in my tests behave the same
> in Wine and Windows.
>

Even without -lucrt ?
The ucrt adds those api-ms-win-crt-* dependencies, which do not seem to be
necessary.

Thank you for the effort, perhaps something strange is happening with my
setup, I could not find anyone else on internet with this issue.

-- 
Marius

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

2019-11-20 Thread Bernhard Übelacker 
Hello Marius Mikucionis,
I am not anyhow involved in maintaining mingw-w64.
But I guess I found something.

First I fear that mingw-w64 does not link as much static
as you expect it to.
All crossbuilt executables still dynamically link to msvcrt.dll.

$ i686-w64-mingw32-objdump -p strftime-6.exe | grep 'DLL Name:'
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

And the Microsoft page might just be right for later versions
of c runtimes they provide.

Further I found this information [2], which is as far as
I understand about recompiling mingw.
But I tried just to modify the compile/link command,
which I guess is kind of the expected output?

$ i686-w64-mingw32-gcc -static -O3 -Wall -o strftime-ucrt-7.exe strftime.c 
-lucrt
$ i686-w64-mingw32-objdump -p strftime-ucrt-7.exe | grep 'DLL Name:'
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: api-ms-win-crt-environment-l1-1-0.dll
DLL Name: api-ms-win-crt-heap-l1-1-0.dll
DLL Name: api-ms-win-crt-private-l1-1-0.dll
DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
DLL Name: api-ms-win-crt-string-l1-1-0.dll
DLL Name: api-ms-win-crt-time-l1-1-0.dll

$ wine strftime-ucrt-7.exe
[%a]: [Tue]
[%e]: [ 5]
[%d]: [05]
[%-d]: (empty) errno=22
[%#d]: [5]
[%b]: [Nov]
[%Y]: [2019]
[%H]: [03]
[%M]: [02]
[%S]: [01]
[%z]: [+0100]
[%Z]: [Mitteleuropõische Zeit]
[%b%e, %Y, %H:%M:%S %z]: [Nov 5, 2019, 03:02:01 +0100]

(msvcrt.dll still appears; the same result for 7.0.0-2 and 6.0.0-3.)


So maybe you could examine this binaries from 2014 if they
need also some Dlls?

At least the binaries produced in my tests behave the same
in Wine and Windows.

Kind regards,
Bernhard


[1] 
https://stackoverflow.com/questions/55728544/how-to-avoid-msvcrt-dll-compiling-with-mingw64

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

2019-11-20 Thread Marius Mikucionis 
Package: mingw-w64-x86-64-dev
Version: 7.0.0-2
Severity: normal

Dear Maintainer,

I am trying to get a string representation of a date via strftime function.
For some reason the function call fails whenever format contains %e (day of 
month with leading space instead of zero).
Also %z (time zone offset) results in "Central Europe Standard Time" (time zone 
name) instead of +0100 or + (the time zone offset).

Here is a small program "strftime.c" demonstrating the issue:

#include 
#include 
#include 
#include 

const char* get_str(char* buf, size_t max, const char* format, const struct tm* 
lt)
{
snprintf(buf, max, "failure");
size_t sz = strftime(buf, max, format, lt);
if (sz==0 && buf[0]==0)
snprintf(buf, max, "(empty) errno=%d", errno);
return buf;
}

int main(){
const char* format[] = {"[%a]","[%e]","[%d]","[%-d]","[%#d]","[%b]",
"[%Y]", 
"[%H]","[%M]","[%S]",
"[%z]", "[%Z]", "[%b%e, 
%Y, %H:%M:%S %z]"};
const size_t format_sz = sizeof(format)/sizeof(format[0]);
//  sec min hr DoM  MoYear  DoW  DoY  dst
struct tm mytime = {  1,  2, 3,  5, 11-1, 2019-1900,  2, 308,   0 };
char buf[256];
for (unsigned int i=0; ihttps://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?view=vs-2019

Best regards,
Marius

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mingw-w64-x86-64-dev depends on:
ii  mingw-w64-common  7.0.0-2

mingw-w64-x86-64-dev recommends no packages.

Versions of packages mingw-w64-x86-64-dev suggests:
ii  wine64  4.0.2-1

-- no debconf information