From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AA8C93858D38; Sun, 5 Mar 2023 23:42:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA8C93858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678059749; bh=9l8BOxpEB6WAzdm88+2vAVBjj8dFVy1lKbfJ9SHfFnY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ey92dDMQz/kbGTBqPvflm5kFaQJmR9PMMdSA2fh7sQpvs/TmEyJDxm0LivBZFbEEa Kf0zhb/dpCWn8rHHxiuV0U+BR8rddDzjV5P1srdrpKenKDr2lx7BcNlLtcuN2nKmMb +inZCtE7XCLuCYs9iQfO3ohyQ7J9hnNkgltPlBwg= 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: Sun, 05 Mar 2023 23:42:29 +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: attachments.isobsolete attachments.created 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 Costas Argyris changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #54559|0 |1 is obsolete| | --- Comment #17 from Costas Argyris --- Created attachment 54589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D54589&action=3Dedit Link utf8 resource object in both driver and compiler The proposed patch addresses the issue of the resource (utf8) object file getting dropped from the compiler link due to not having any references to = it inside libbackend.a, by creating an artificial symbol and requiring it to be present in the compiler link. More precisely, a dummy object file is created with the dummy symbol, and t= hat object file gets combined with the resource object into a third object file that has both the utf8 resource and the symbol. That way, by requiring the symbol to be defined at compiler link we are for= cing the resource object to be linked into the compiler proper. The driver has no such issue as it doesn't link to the resource object thro= ugh a static library, but as an object directly (this was already working from = the previous patch). This now works end-to-end, since I was able to fully use both gcc and g++ w= ith unicode paths and it succeeded. So both drivers (gcc.exe and g++.exe) and compilers (cc1.exe and cc1plus.exe) handled the unicode paths just fine.=