[Bug driver/108865] gcc on Windows fails with Unicode path to source file

["costas.argyris at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865

--- Comment #11 from Costas Argyris <costas.argyris at gmail dot com> ---
Capturing another data point:

I hex-compared an executable before and after applying the UTF-8 manifest with
mt.exe just to try and see what it does, and I noticed a few things:

1) The executable size was almost cut in half.    It was compiled with gcc in
the first place so maybe it stripped the debug symbols perhaps?

2) There were various changes throughout it, not just the part of the xml
manifest that was embedded.

3) The format changed to the point that gdb was no longer able to understand
it.    Before applying the manifest with mt.exe, I was able to load it into gdb
and debug it, not after though as it complains about unknown format.

Of course, it still runs fine after those changes.

So clearly mt.exe does a lot more to the executable than just link in the
manifest.    I would expect that something similar happens when the manifest
gets integrated at build time with MSVC.

It doesn't look like it's a simple "just compile and link the resource file"
case, as that seems to be only part of what is necessary, not the entire
procedure.

So with my current understanding of the situation I think that the plan of
integrating the UTF-8 manifest at gcc build time with GNU tools is simply not
possible.

I would love to be proven wrong, but if it's not happening we either have to go
for another approach, or just accept that gcc will not support Unicode paths on
Windows (in which case we could at least copy the instructions to do it with
mt.exe in some wiki guide).