gcc/ld doesn't support unicode paths

[Kojoley]

Description / Steps to reproduce the issue

MINGW64 /tmp
$ mkdir uni♥code

MINGW64 /tmp
$ echo uni♥code > uni♥code/test

MINGW64 /tmp
$ cat uni♥code/test
uni♥code

MINGW64 /tmp
$ echo 'int main() {}' > a.cpp

MINGW64 /tmp
$ g++ a.cpp -o a.o

MINGW64 /tmp
$ g++ a.cpp -o uni♥code/a.o
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe
: cannot open output file uni♥code/a.o: No such file or directory
collect2.exe: error: ld returned 1 exit status

MINGW64 /tmp
$ ld a.o -o a.exe

MINGW64 /tmp
$ ld a.o -o uni♥code/a.exe
C:\msys64\mingw64\bin\ld.exe: cannot open output file uni♥code/a.exe: No such file or directory

Expected behavior

Should produce an object/executable.

Actual behavior

Fails with error.

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-19045

MINGW environments affected

• MINGW64
• MINGW32
• UCRT64
• CLANG64
• CLANG32
• CLANGARM64

Are you willing to submit a PR?

No response

[takulark]

Unicode version gcc&binutils Unless it's
In the first place, I think it is impossible.

[RivenSkaye]

Looks like an issue between UTF-16 (wide strings) and UTF-8; with the former being the encoding of choice on Windows it's reinterpreting the heart as two UTF-8 surrogate pairs instead of a single UTF-16 pair. I wonder if that's fixable at all, especially considering how GNU thinks about wchar_t being UTF-16

[nongwoluanlai666]

+1
ld.exe: cannot find D:/桌面/svnproj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/crtend.o: No such file or directory

[sskras]

On MSYS2 and Cygwin the binary gets built, but running it generates a segfault:

saukrs@DESKTOP-O7JE7JE MSYS ~
$ uni♥code/a.exe
Segmentation fault

saukrs@DESKTOP-O7JE7JE MSYS ~
$ ./a.exe
Segmentation fault

saukrs@DESKTOP-O7JE7JE MSYS ~
$ uname -a
MSYS_NT-10.0-19044 DESKTOP-O7JE7JE 3.4.9.x86_64 2023-09-15 12:15 UTC x86_64 Msys

Midipix on the other hand goes without a crash:

midipix@DESKTOP-O7JE7JE ~
$ uni♥code/a.exe; echo $?
29

midipix@DESKTOP-O7JE7JE ~
$ uname -a
midipix DESKTOP-O7JE7JE pre-alpha-internal-2bc731105275d52feb98f3b47cf454e7674ab739 2022.11.18.20.22.52 x86_64 Midipix

But the exit code is non-zero.

[RivenSkaye]

Looking through their website, midipix does a lot of work to make sure the extra steps in UTF-16LE conversions work as they should; I wonder if artifacts compiled on their toolchain have the same conversions linked in though

[szw0407]

The package may help a little:

https://packages.msys2.org/base/mingw-w64-unicode-character-database

However, it still has some issues. For example when I do such things:

gcc 测试.c -o 测试

As expected there should be a 测试.exe in the folder if compiled successfully. However, even if compiled successfully, there is only one file named ����.exe. It seems that the source file referred to is found and opened successfully, but the output file is still not correct.

There are other issues no matter whether the beta UNICODE support on Windows is enabled or not. Perhaps that is really an issue with encoding but not Unicode support.