-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ld
does not work with non-ASCII file path
#649
Comments
@CyanoHao could you please provide the PR for the |
@CyanoHao do you want me to release a new build with this patch before closing this issue? |
same problem, please release a new build, thanks |
@CyanoHao If the installation directory of MinGW-w64 contains Chinese Characters, then compilation will fail. C:\编译器MinGW64\bin\g++.exe "C:\myprogs\hello.cpp" -o "C:\编译器hello.exe" -Wall -Wextra -pipe -I"C:\编译器MinGW64\include" -I"C:\编译器MinGW64\x86_64-w64-mingw32\include" -I"C:\编译器MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include" -I"C:\编译器MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include\c++" -L"C:\编译器MinGW64\lib" -L"C:\编译器MinGW64\x86_64-w64-mingw32\lib" -static-libstdc++ -static-libgcc The compilation will fail, and the output message is: C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o: No space left on device It seems that the Chinese characters "编译器" are ignored in some internal stage. |
I also tested v12.2 and v11.2. Compiling command with v12.2: Output message: It seems that the Chinese characters "编译器" are not ignored in message, but ignored in some internal stage. Compiling command with v11.2: Regardless of whether my source code has errors or not, v11.2 works OK. |
@anbangli It seems okay now (tested with x86_64-posix-seh-ucrt build). |
These are upstream bugs (2 bugs as far as I know), and seem can be fixed with a patch for binutils.
1st bug: slash conversion in
ld
breaks wide filename.This is cause by a mistake in variable name in
FILE *_bfd_real_fopen(const char *filename, const char *modes)
(binutils-2.39/bfd/bfdio.c
).It should be
2nd bug:
ld
gets wrong active code page with___lc_codepage_func()
. (MSVCRT only)This is caused by a tricky problem in
FILE *_bfd_real_fopen(const char *filename, const char *modes)
(binutils-2.39/bfd/bfdio.c
). In a word, MSVCRT version ofUINT ___lc_codepage_func(void)
, which is invoked byld
to determine current code page, does not return system code page or active code page. Instead, it returns default code page for Windows display language. (UCRT version is okay.)Changing
___lc_codepage_func()
toCP_ACP
seems to fix this bug. But I’m not sure whether there are some conner cases that would be broken.Here is a simple program to test
___lc_codepage_func()
.With release of 13.1.0-rt_v11-rev1, x86-64 POSIX SEH:
(MSVCRT result for case 1 and 2:)
(UCRT result for case 1 and 2:)
Patch
By the way, if someone would like to fix it in upstream, a minor problem in this function can also be fixed:
A length of
fullPathWSize + (sizeof(prefix) / sizeof(wchar_t) - 1) + 1
is sufficient.The text was updated successfully, but these errors were encountered: