[Bug driver/108865] gcc on Windows fails with Unicode path to source file

["costas.argyris at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.