Codepage issue on Windows 8.1 #8263
Comments
|
Yes, that looks like our bug. We should probably be using utf-8 or ascii for the encoding. What do you think @jpakkane (since this is your code)? I don't have access to windows 8 anymore, If we wrote a patch would you be able to test it? |
|
I can make a best effort, run code/patches you send me, and rummage around trying things. However, I am totally new to meson and vcpkg. |
|
I think this is likely a meson + harfbuzz problem, looking at the output. It would be interesting to see if you can reproduce this building harfbuzz with meson outside vcpkg. |
|
I just tried building harfbuzz-master with meson outside vcpkg, and it was successful (no errors). I tried building the harfbuzz tarball that vcpkg downloads, and also succeeded with |
|
We're currently triggering this same issue in Mesa on Windows, so maybe it's worth tossing out a patch that passes an encoding-argument to |
|
Some more digging shows that this Python change is what caused the regression in Mesa. |
|
@kusma Could you also report this to upstream Python, since this is a Python bug apparently? Also, we are using |
|
I already did: https://bugs.python.org/issue44487 |
|
Seems like with #7295 we should really consider patching |
|
That ticket only seem superficially connected to this one as far as I can tell; #7295 seems to be about the path, whereas this is about the encoding of the content of the file. |
|
Yeah, but the solution for Meson is the same: Patch the |
|
Yeah, fair enough. |
|
fwiw, I would recommend not waiting for Python to fix this issue. The best way forward IMHO is:
|
|
Already working on it :) |
|
Rather than monkeypatching, it would be better to change the call sites. The thing about monkeypatching is that it always comes back to bite you in the ass. |
|
Here's a minimal reproduction: lib.cpp: extern const char *utf8_encoded[] = {
"▘", "▝", "▀",
"▖", "▌", "▞", "▛",
"▗", "▚", "▐", "▜",
"▄", "▙", "▟", "▉"
};meson.build: |
|
@jpakkane The problem with changing the call sites is that there are just so many, and that every With monkey patching, we have a dirty hack (just for Windows) in one location and don't have to worry about the remaining code base. Not saying that I like the idea, but that it is better (IMHO) than fixing 66 (for |
I agree, if it's not too difficult to find all the call-sites. I thought the problem in this case was that not just that |
|
It seems that reproduction case, which is taken from the mesa sources, fails even with Meson 0.57.2 and with Python 3.9.5. So It's a bit unclear to me if the python change I blamed is the actual culprit. Still, we're seeing this passing on CI with recent-ish images, so something changed. Unfortunately, I think we've lost the logs for when the current base-image was built, so I don't think it's easy to inspect the details closely. There's a lot of conditions in Maybe this is about the VS version instead of all the other things I've suspected so far? 26ffd4f mentions "Currently only the preview version of Visual Studio is supported". And since this triggers for me, it seems a new non-preview Visual Studio version has been released, and it might support this. So if our build-image all of a sudden picked up a new Visual Studio version, it could be that we started triggering a previously latent bug. |
Even then I would argue that we have way too many and no automatic way to ensure that they are correctly maintained... |
|
Looks like this issue at least really isn't a python bug, but a major python annoyance: On Windows, UTF-8 is not the default charmap, but something else based on the locale: This results in your error when meson reads files on Windows. |
|
@kusma Setting |
|
Python 3.10 has |
|
Nice, setting |
|
Unfortunately, |
|
Yeah, but we can use it on CI for Mesa until a real fix has landed :) Just my two cents; I think just patching this particular call to |
|
We mostly use |
|
Should be fixed/worked around with #8918. |
Describe the bug
I receive a build failure when building
harfbuzzthroughvcpkg.vcpkgmaintainers believe it is amesonupstream bug with codepages. The downstream bug is microsoft/vcpkg#15916. I have no ability to file a sane bug report, since I know nothing. However, I have logs.To Reproduce
I can only reproduce this when building harfbuzz with vcpkg, using
./vcpkg install harfbuzz. I don't receive this error when building harfbuzz with the project's native meson instructions without vcpkg. These builds are on the same system, but my native build uses mingw-w64's gcc, while the vcpkg build uses Visual Studio. The compiler isn't yet invoked when the build error occurs, so I don't believe this difference of compilers is the cause.Expected behavior
I expected it to build cleanly. This is the log:
Attached: src\harfbuzz.dll.p\harfbuzz.dat
Attached: package-x64-windows-rel-out.log, probably no need to look at this
system parameters
The text was updated successfully, but these errors were encountered: