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).
