"setlocale failed" on Windows

[y-guyon]

Issue

avifenc.exe 1.PNG 1.avif fails when avifenc.exe is downloaded from https://ci.appveyor.com/project/louquillio/libavif/builds/48799163 (built with Visual Studio 2022 Developer Command Prompt v17.8.2 according to the the log and run in Visual Studio 2022 Developer Command Prompt v17.1.0 prompt):

setlocale failed

Expected behavior

Building and running avifenc locally worked, see #1889 (comment) (Visual Studio 2022 Developer Command Prompt v17.1.0 prompt).

Environment

Windows Server 2016 Datacenter (Google Compute Engine Virtual Machine, Intel Xeon x64)

[y-guyon]

@louquillio

[kmilos]

I guess one would need to check UCRT is being used rather than MSVCRT in order for setlocale to work. Also, Windows 10 1903 or later is a minimum requirement for UTF-8 locales. @vrabaud

[vrabaud]

How can you figure that out in Windows given a binary? What is the equivalent of the Unix' ldd?
From the logs, it seems CMake is doing the default which should be UCRT right?

[kmilos]

How can you figure that out in Windows given a binary? What is the equivalent of the Unix' ldd?

Yep, either using MSYS2 tools equivalents (ldd/ntldd), or something like https://github.com/lucasg/Dependencies or https://www.dependencywalker.com/

UCRT should be the default since VS 2015 according to MS, but I haven't used it in a very long time, sorry...

[wantehchang]

We can use the "dumpbin /dependents avifenc.exe" command.

Running that command on a local build I did on 2023-10-27, I get:

  Image has the following dependencies:

    KERNEL32.dll
    VCRUNTIME140D.dll
    ucrtbased.dll

Running that command on avifenc.exe I downloaded from AppVeyoer, I get:

  Image has the following dependencies:

    KERNEL32.dll
    VCRUNTIME140.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-utility-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll

[y-guyon]

I got the same dumpbin results as #1896 (comment).

[wantehchang]

Yannis: When I run the avifenc.exe downloaded from https://ci.appveyor.com/project/louquillio/libavif/builds/48799163, I am not getting the "setlocale failed" error.

I think the problem may be the version of Windows you are using: Windows Server 2016 Datacenter (Google Compute Engine Virtual Machine, Intel Xeon x64)

As for the different "dumpbin /dependents avifenc.exe" outputs, I guess it is caused by whether the binary was built using Ninja or Visual Studio.

[wantehchang]

Assuming we can trust the info in https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

Windows 10 1903 is version 1903, build 18362.

The corresponding server version of Windows is "Windows Server, version 1903". That is newer than Windows Server 2019.

So Windows Server 2016 Datacenter is unlikely to support UTF-8 locales, and our setlocale(LC_ALL, ".UTF8") call is expected to fail.

I guess we should improve or delete that error message.

[wantehchang]

Another option is to detect the runtime Windows version and call setlocale(LC_ALL, ".UTF8") only if it's version 1903 or higher. Then it is fine to print an error message if the setlocale() call fails.

[wantehchang]

I looked into detecting the runtime Windows version. It now requires reading registry keys. I think it's not worth the trouble. I suggest we just ignore the return value of the setlocale() call.

[y-guyon]

I still have the same issue in the same environment. Running Appveyor's avifenc outputs setlocale failed.

[kmilos]

The Appveyor log has:

-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.17763.

Perhaps a target matching at least Windows 10 1903 (so 10.0.18362 as described above) is needed?

[wantehchang]

Yannis: Thank you for verifying the fix. Please test this build instead: https://ci.appveyor.com/project/louquillio/libavif/builds/48905179/artifacts

The build you tested was an experimental pull request to revert my fix. So it didn't have the bug fix.

[y-guyon]

Yannis: Thank you for verifying the fix. Please test this build instead: https://ci.appveyor.com/project/louquillio/libavif/builds/48905179/artifacts

This binary works, thanks.

The build you tested was an experimental pull request to revert my fix. So it didn't have the bug fix.

Right, I got confused. It is fixed then.

[wantehchang]

Apparently the AppVeyor builds at https://ci.appveyor.com/project/louquillio/libavif/history are a mixture of pull requests and commits. Users may unknowingly download a bad "current build" from there if it is built from a pull request.