[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

--- Comment #25 from Costas Argyris <costas.argyris at gmail dot com> ---
Some more specific info:

Host x86_64-w64-mingw32 in general didn't fail.    What failed was building it
as an MSYS2 package using the PKGBUILD script.    For example, cross-compiling
with standard configure + make didn't fail.

On the reason of the MSYS2 package build failure:

When building using that approach, the following executables

build/genchecksum.exe    build/genmodes.exe    build/genversion.exe   
build/gengenrtl.exe

are borrowing the $(COMPILERS) flags, so this included

-Wl,--require-defined=HOST_EXTRA_OBJS_SYMBOL

because of

+$(COMPILERS) : override LDFLAGS +=
-Wl,--require-defined=HOST_EXTRA_OBJS_SYMBOL

Since '--require-defined' results in an error if the symbol is not found, the
failure happens.    This shouldn't be an error though, because this flag was
only meant for the compilers, hence the $(COMPILERS) variable.    I don't know
why these executables use the compiler flags in this build setup.    It didn't
happen when cross-compiling using configure + make.

The proposed patch simply switches '--require-defined' to '--undefined' and
makes the symbol definition optional, so these executables don't fail to build.
   The compilers will still pull it in, so we still get the UTF-8 feature.

With the proposed patch, the MSYS2 gcc package builds fine.    Also confirmed
for the cross-compilation case with configure + make.