2019-11-21, th, 13:14 Bernhard Übelacker <bernha...@mailbox.org> 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
