https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Costas Argyris from comment #17) > Created attachment 54589 [details] > 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. Neat trick. > > 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. That is good news.
