From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B6E273858401; Wed, 1 Mar 2023 10:38:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B6E273858401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677667131; bh=6Us+RhV6Og/iBfpw9qi2POcUgOl9FmvimFJSzQ8v6FE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Gda5U1nqzCYqSsq2dkYNnxiOT5sYR957QH5cOPZXt3zxyOomAzqixuX1bca+XIgtj 8r1DWgIlzDvAs7swt/ctbzQWKMWTdEd1XmyGrTYXZNF2dZHhTQf6FSIwnPorNeBsqe 3cngtCoOq8OWMtxvAFkSryQDmPZK3osxgRJKgFKk= From: "costas.argyris at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug driver/108865] gcc on Windows fails with Unicode path to source file Date: Wed, 01 Mar 2023 10:38:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: driver X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: costas.argyris at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108865 --- Comment #11 from Costas Argyris --- Capturing another data point: I hex-compared an executable before and after applying the UTF-8 manifest w= ith 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 n= ot possible. I would love to be proven wrong, but if it's not happening we either have t= o go for another approach, or just accept that gcc will not support Unicode path= s on Windows (in which case we could at least copy the instructions to do it with mt.exe in some wiki guide).=