https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Costas Argyris <costas.argyris at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #54559|0 |1 is obsolete| | --- Comment #17 from Costas Argyris <costas.argyris at gmail dot com> --- Created attachment 54589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54589&action=edit 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 that 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 forcing 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 through 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++ with 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.