odd number of bytes in UTF16 mode

[alandefreitas]

Hi,

Thank you so much for that. It will be such a relief to stop switching to windows just to test the MSVC hacks.

CMake has been working fine and building that simple program mentioned in the README.md.

Then I get this weird

0214:err:msvcrt:read_i got odd number of bytes in UTF16 mode

error.

Here is the complete output for the library I'm trying to build, just in case.

Do people go through that very often?

I'm really a noob here, so this might be a stupid issue.

[mstorsjo]

I haven't seen this issue before - it seems either like a wine bug/issue (might be dependent on what version of wine you use) and/or some MSVC specific behaviour that hasn't been tested/triggered so far. Can you reproduce the issue with a public simple testcase, e.g. the one from cmake? If you can reproduce it there, it sounds like an issue with your version of wine. If not, you need to provide a testcase where I can reproduce the issue.

[fastcoding]

I met the same issue on macos 12.5.1 (m1 processor) with crossover(wine version 6.0) from homebrew.
This only happens when a response file is used in command line as cmake would in link.txt.

$ cat resp.txt
/out h.exe hello.obj

$ ../msvc/bin/x64/link '@resp.txt'

output:

0094:err:plugplay:process_IOService_Device object 0x5903
0024:err:msvcrt:read_i got odd number of bytes in UTF16 mode
0024:err:msvcrt:read_i got odd number of bytes in UTF16 mode
Microsoft (R) Incremental Linker Version 14.32.31332.0
Copyright (C) Microsoft Corporation.  All rights reserved.

?????????? 
LINK : fatal error LNK1181: cannot open input file '??????????.obj'

[mstorsjo]

I tested linking with a response file like that, but it seems to work fine for me, with wine 7.0. But it does sound a lot like a bug that appeared late in the wine 5.x series and was present in 6.0, but got fixed in 6.1 (and 6.0.1): https://source.winehq.org/git/wine.git/commitdiff/be1c8a56a39e03e13446a26d12bdacafbd57ee37?hp=5faad354d84bac04fac12a8730de2403353cb91c

[fastcoding]

Thus adding a BOM to resp.txt can fix this issue:

$ vim resp.txt
:set bomb 
:w resp.txt 

run link again, all errors are gone.
but anyway to add this workaround to cmake?

[mstorsjo]

Thus adding a BOM to resp.txt can fix this issue:

$ vim resp.txt
:set bomb 
:w resp.txt 

run link again, all errors are gone. but anyway to add this workaround to cmake?

I'm not sure how easy it is to fix that way - I think it's easiest just to update to a version of wine with the bug patched.

[fastcoding]

I'm using crossover-wine on macos with arm processor. upgrading wine version looks like uneasy either - need to rebuild crossover from source by myself.

[fastcoding]

just thought of docker can work on macos and that would be much easier than hack into cmake or crossover-wine.
so this issue can actually be closed. thanks!

[alandefreitas]

That's what I have here:

wine --version
wine-6.0.3 (Ubuntu 6.0.3~repack-1)

I'll test some other version later today.

[mstorsjo]

That's what I have here:

wine --version
wine-6.0.3 (Ubuntu 6.0.3~repack-1)

I'll test some other version later today.

That’s odd - that particular bugfix should have been in 6.0.1 already - maybe there were other related fixes later on too?

[mstorsjo]

Oh, another thing you might want to try: Use the Ninja generator in CMake instead of the default (GNU make). With the makefile generator, CMake seems to prefer to use response files for lots of things, while with Ninja it usually doesn't use response files.

[alandefreitas]

Yes. Updating wine worked. :)

Thanks, guys!

[mstorsjo]

Yes. Updating wine worked. :)

That's great! For reference for other users - what version did you upgrade to, that worked for you?

[alandefreitas]

Sure.

$ wine --version
wine-7.0

Part of the problem is that the default Ubuntu repositories will get you wine 6 unless you follow the instructions in https://wiki.winehq.org/Download

Maybe that information could be on the readme.md. I don't know.