Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Costas Argyris]

[-- Attachment #1.1: Type: text/plain, Size: 509 bytes --]

Hi

This is a proposal for addressing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865

by integrating the UTF-8 manifest file into gcc's build process for the
64-bit mingw host.

The analysis and discussion leading up to the latest patch are written in
the bug report.

The patch attached in this email is exactly the same as the one posted last
in the bug report.

I should also mention that, in case of approval, I would need someone with
write access to make the commit for me please.

Thanks,
Costas

[-- Attachment #2: 0001-Enable-UTF-8-code-page-on-Windows-64-bit-host-PR1088.patch --]
[-- Type: application/octet-stream, Size: 6472 bytes --]

From 278c979d0e7fd093e43c6de99fd6a3d17e23f76a Mon Sep 17 00:00:00 2001
From: Costas Argyris <costas.argyris@gmail.com>
Date: Tue, 28 Feb 2023 17:10:18 +0000
Subject: [PATCH] Enable UTF-8 code page on Windows 64-bit host [PR108865]

Compile a resource object that contains the utf8 manifest.

Then link that object into the driver and compiler proper.

For compiler proper the link has to be forced because the
resource object file gets into a static library (libbackend.a)
and gets eventually dropped because it has no symbols of
its own and nothing is referencing it inside the library.

Therefore, an artificial symbol is planted to force the link.
---
 gcc/config.host                     |  5 +--
 gcc/config/i386/sym-mingw32.cc      |  1 +
 gcc/config/i386/utf8-mingw32.rc     |  3 ++
 gcc/config/i386/winnt-utf8.manifest |  8 +++++
 gcc/config/i386/x-mingw32           |  3 +-
 gcc/config/i386/x-mingw32-utf8      | 56 +++++++++++++++++++++++++++++
 6 files changed, 72 insertions(+), 4 deletions(-)
 create mode 100644 gcc/config/i386/sym-mingw32.cc
 create mode 100644 gcc/config/i386/utf8-mingw32.rc
 create mode 100644 gcc/config/i386/winnt-utf8.manifest
 create mode 100644 gcc/config/i386/x-mingw32-utf8

diff --git a/gcc/config.host b/gcc/config.host
index a522c39658e..4abb32ad73d 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -241,10 +241,11 @@ case ${host} in
   x86_64-*-mingw*)
     use_long_long_for_widest_fast_int=yes
     host_xm_file=i386/xm-mingw32.h
-    host_xmake_file="${host_xmake_file} i386/x-mingw32"
+    host_xmake_file="${host_xmake_file} i386/x-mingw32 i386/x-mingw32-utf8"
     host_exeext=.exe
     out_host_hook_obj=host-mingw32.o
-    host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o"
+    host_extra_objs="${host_extra_objs} utf8-mingw32.o"
+    host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o utf8rc-mingw32.o"
     host_lto_plugin_soname=liblto_plugin.dll
     ;;
   aarch64*-*-darwin*)
diff --git a/gcc/config/i386/sym-mingw32.cc b/gcc/config/i386/sym-mingw32.cc
new file mode 100644
index 00000000000..f369698abc4
--- /dev/null
+++ b/gcc/config/i386/sym-mingw32.cc
@@ -0,0 +1 @@
+char HOST_EXTRA_OBJS_SYMBOL;
diff --git a/gcc/config/i386/utf8-mingw32.rc b/gcc/config/i386/utf8-mingw32.rc
new file mode 100644
index 00000000000..e2174e85b7c
--- /dev/null
+++ b/gcc/config/i386/utf8-mingw32.rc
@@ -0,0 +1,3 @@
+#include <winuser.h>
+
+CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "winnt-utf8.manifest"
diff --git a/gcc/config/i386/winnt-utf8.manifest b/gcc/config/i386/winnt-utf8.manifest
new file mode 100644
index 00000000000..dab929e1515
--- /dev/null
+++ b/gcc/config/i386/winnt-utf8.manifest
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
+  <application>
+    <windowsSettings>
+      <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
+    </windowsSettings>
+  </application>
+</assembly>
diff --git a/gcc/config/i386/x-mingw32 b/gcc/config/i386/x-mingw32
index 5b8b5f96143..cb3d8434881 100644
--- a/gcc/config/i386/x-mingw32
+++ b/gcc/config/i386/x-mingw32
@@ -27,8 +27,7 @@ WERROR_FLAGS += -Wno-format
 
 host-mingw32.o : $(srcdir)/config/i386/host-mingw32.cc $(CONFIG_H) $(SYSTEM_H) \
   coretypes.h hosthooks.h hosthooks-def.h toplev.h $(DIAGNOSTIC_H) $(HOOKS_H)
-	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-		$(srcdir)/config/i386/host-mingw32.cc
+	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<
 
 driver-mingw32.o : $(srcdir)/config/i386/driver-mingw32.cc $(CONFIG_H)
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<
diff --git a/gcc/config/i386/x-mingw32-utf8 b/gcc/config/i386/x-mingw32-utf8
new file mode 100644
index 00000000000..6161dc23547
--- /dev/null
+++ b/gcc/config/i386/x-mingw32-utf8
@@ -0,0 +1,56 @@
+# Copyright (C) 2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+#
+#
+# For 64-bit Windows host, embed a manifest that sets the active
+# code page of the driver and compiler proper processes to utf8.
+# This only has an effect on Windows version 1903 (May 2019 Update)
+# or later.
+
+# The resource .rc file references the utf8 .manifest file.
+# Compile it into an object file using windres.
+# The resulting .o file gets added to host_extra_gcc_objs in
+# config.host for x86_64-*-mingw* host and gets linked into
+# the driver as a .o file, so it's lack of symbols is OK.
+utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc
+	$(WINDRES) $< $@
+
+# Create an object file that just exports the global symbol
+# HOST_EXTRA_OBJS_SYMBOL
+sym-mingw32.o : $(srcdir)/config/i386/sym-mingw32.cc
+	$(COMPILER) -c $< $@
+
+# Combine the two object files into one which has both the
+# compiled utf8 resource and the HOST_EXTRA_OBJS_SYMBOL symbol.
+# The resulting .o file gets added to host_extra_objs in
+# config.host for x86_64-*-mingw* host and gets archived into
+# libbackend.a which gets linked into the compiler proper.
+# If nothing references it into libbackend.a, it will not
+# get linked into the compiler proper eventually.
+# Therefore we need to request the symbol at compiler link time.
+utf8-mingw32.o : utf8rc-mingw32.o sym-mingw32.o
+	$(COMPILER) -r utf8rc-mingw32.o sym-mingw32.o -o $@
+
+# Force compilers to link against the utf8 resource by
+# requiring the symbol to be defined.
+# Otherwise the object file won't get linked in the compilers
+# because nothing is referencing it in libbackend.a
+# This is expected because the resource object is not supposed
+# to have any symbols, it just has to be linked into the
+# executable in order for Windows to use the utf8 code page.
+$(COMPILERS) : override LDFLAGS += -Wl,--require-defined=HOST_EXTRA_OBJS_SYMBOL
-- 
2.30.2

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Jacek Caban]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

Hi Costas,

On 3/7/23 01:52, Costas Argyris via Gcc-patches wrote:
> This is a proposal for addressing
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
>
> by integrating the UTF-8 manifest file into gcc's build process for the
> 64-bit mingw host.


Is there a reason to make it specific to x86_64? It seems to me that all 
mingw hosts could use it.


>
> +# The resource .rc file references the utf8 .manifest file.
> +# Compile it into an object file using windres.
> +# The resulting .o file gets added to host_extra_gcc_objs in
> +# config.host for x86_64-*-mingw* host and gets linked into
> +# the driver as a .o file, so it's lack of symbols is OK.
> +utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc
> +	$(WINDRES) $< $@


I think that .manifest file should also be a dependency here.


Thanks,

Jacek

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Costas Argyris]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

Hi Jacek,

"Is there a reason to make it specific to x86_64? It seems to me that all
mingw hosts could use it."

Are you referring to the 32-bit host?    My concern here is that this
functionality (embedding the UTF-8
manifest file into the executable) is only truly supported in recent
versions of Windows.    From:

https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

It says that Windows Version 1903 (May 2019 Update) enables this, so we are
looking at the 64-bit
version of Windows.

I suppose you are referring to the scenario where one has a 32-bit gcc +
mingw running in a 64-bit
Windows that is recent enough to support this?    It is not clear to me
based on the above doc what
would happen encoding-wise in that situation, and I haven't tried it either
because I assumed that
most people would want the 64-bit version of gcc since they are probably
running a 64-bit OS.

If you think it is useful, I could look into that as a separate task to try
and keep this one simple, if
that makes sense.

"I think that .manifest file should also be a dependency here."

Why is that?    Windres takes only the .rc file as its input, as per its
own doc, and it successfully
compiles it into an object file.    The .manifest file is only referenced
by the .rc file, and it doesn't
get passed to windres, so I don't see why it has to be listed as a
prerequisite in the make rule.

Thanks,
Costas

On Tue, 7 Mar 2023 at 12:02, Jacek Caban <jacek@codeweavers.com> wrote:

> Hi Costas,
>
> On 3/7/23 01:52, Costas Argyris via Gcc-patches wrote:
>
> This is a proposal for addressing
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
>
> by integrating the UTF-8 manifest file into gcc's build process for the
> 64-bit mingw host.
>
>
> Is there a reason to make it specific to x86_64? It seems to me that all
> mingw hosts could use it.
>
>
>
> +# The resource .rc file references the utf8 .manifest file.
> +# Compile it into an object file using windres.
> +# The resulting .o file gets added to host_extra_gcc_objs in
> +# config.host for x86_64-*-mingw* host and gets linked into
> +# the driver as a .o file, so it's lack of symbols is OK.
> +utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc
> +	$(WINDRES) $< $@
>
>
> I think that .manifest file should also be a dependency here.
>
>
> Thanks,
>
> Jacek
>

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Jacek Caban]

Hi Costas,

On 3/7/23 15:00, Costas Argyris wrote:
> Hi Jacek,
>
> "Is there a reason to make it specific to x86_64? It seems to me that 
> all mingw hosts could use it."
>
> Are you referring to the 32-bit host?    My concern here is that this 
> functionality (embedding the UTF-8
> manifest file into the executable) is only truly supported in recent 
> versions of Windows.    From:
>
> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
>
> It says that Windows Version 1903 (May 2019 Update) enables this, so 
> we are looking at the 64-bit
> version of Windows.
>
> I suppose you are referring to the scenario where one has a 32-bit 
> gcc + mingw running in a 64-bit
> Windows that is recent enough to support this?    It is not clear to 
> me based on the above doc what
> would happen encoding-wise in that situation, and I haven't tried it 
> either because I assumed that
> most people would want the 64-bit version of gcc since they are 
> probably running a 64-bit OS.
>
> If you think it is useful, I could look into that as a separate task 
> to try and keep this one simple, if
> that makes sense.


Yes, realistically it's mostly about 32-bit gcc on 64-bit Windows 
(perhaps aarch64 as well at some point in the future). It's probably 
indeed not very popular configuration those days, but I think it should 
work just fine if you didn't explicitly limit the patch to x86_64.


> "I think that .manifest file should also be a dependency here."
>
> Why is that?    Windres takes only the .rc file as its input, as per 
> its own doc, and it successfully
> compiles it into an object file.    The .manifest file is only 
> referenced by the .rc file, and it doesn't
> get passed to windres, so I don't see why it has to be listed as a 
> prerequisite in the make rule.


The point that when winnt-utf8.manifest is modified, utf8-mingw32.o 
should be rebuilt. Anyway, it's probably not a big deal (I should 
disclaim that I'm not very familiar with gcc build system; I'm mostly on 
this ML due to mingw-w64 contributions).


Thanks,

Jacek

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Costas Argyris]

[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]

Hi Jacek,

"but I think it should work just fine if you didn't explicitly limit the
patch to x86_64."

I would think so too.

Actually, even cygwin might benefit from this, assuming it has the same
problem, which I don't know if it's the case.

But I'm not experienced with that so I would like to explore these hosts
separately and just focus on the most common 64-bit Windows host with this
change, if possible.

"The point that when winnt-utf8.manifest is modified, utf8-mingw32.o should
be rebuilt."

Right, makes sense.

Just noting that winnt-utf8.manifest is really not meant to be modified,
because it is copied straight from:

https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

and will probably remain like that, but I do get your point and I am happy
to make the change.

Thanks,
Costas

On Tue, 7 Mar 2023 at 14:18, Jacek Caban <jacek@codeweavers.com> wrote:

> Hi Costas,
>
> On 3/7/23 15:00, Costas Argyris wrote:
> > Hi Jacek,
> >
> > "Is there a reason to make it specific to x86_64? It seems to me that
> > all mingw hosts could use it."
> >
> > Are you referring to the 32-bit host?    My concern here is that this
> > functionality (embedding the UTF-8
> > manifest file into the executable) is only truly supported in recent
> > versions of Windows.    From:
> >
> >
> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
> >
> > It says that Windows Version 1903 (May 2019 Update) enables this, so
> > we are looking at the 64-bit
> > version of Windows.
> >
> > I suppose you are referring to the scenario where one has a 32-bit
> > gcc + mingw running in a 64-bit
> > Windows that is recent enough to support this?    It is not clear to
> > me based on the above doc what
> > would happen encoding-wise in that situation, and I haven't tried it
> > either because I assumed that
> > most people would want the 64-bit version of gcc since they are
> > probably running a 64-bit OS.
> >
> > If you think it is useful, I could look into that as a separate task
> > to try and keep this one simple, if
> > that makes sense.
>
>
> Yes, realistically it's mostly about 32-bit gcc on 64-bit Windows
> (perhaps aarch64 as well at some point in the future). It's probably
> indeed not very popular configuration those days, but I think it should
> work just fine if you didn't explicitly limit the patch to x86_64.
>
>
> > "I think that .manifest file should also be a dependency here."
> >
> > Why is that?    Windres takes only the .rc file as its input, as per
> > its own doc, and it successfully
> > compiles it into an object file.    The .manifest file is only
> > referenced by the .rc file, and it doesn't
> > get passed to windres, so I don't see why it has to be listed as a
> > prerequisite in the make rule.
>
>
> The point that when winnt-utf8.manifest is modified, utf8-mingw32.o
> should be rebuilt. Anyway, it's probably not a big deal (I should
> disclaim that I'm not very familiar with gcc build system; I'm mostly on
> this ML due to mingw-w64 contributions).
>
>
> Thanks,
>
> Jacek
>
>

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Costas Argyris]

[-- Attachment #1.1: Type: text/plain, Size: 3368 bytes --]

Added .manifest file to the make rule for utf8rc-mingw32.o, latest patch
attached.

On Tue, 7 Mar 2023 at 15:27, Costas Argyris <costas.argyris@gmail.com>
wrote:

> Hi Jacek,
>
> "but I think it should work just fine if you didn't explicitly limit the
> patch to x86_64."
>
> I would think so too.
>
> Actually, even cygwin might benefit from this, assuming it has the same
> problem, which I don't know if it's the case.
>
> But I'm not experienced with that so I would like to explore these hosts
> separately and just focus on the most common 64-bit Windows host with this
> change, if possible.
>
> "The point that when winnt-utf8.manifest is modified, utf8-mingw32.o
> should be rebuilt."
>
> Right, makes sense.
>
> Just noting that winnt-utf8.manifest is really not meant to be modified,
> because it is copied straight from:
>
>
> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
>
> and will probably remain like that, but I do get your point and I am happy
> to make the change.
>
> Thanks,
> Costas
>
> On Tue, 7 Mar 2023 at 14:18, Jacek Caban <jacek@codeweavers.com> wrote:
>
>> Hi Costas,
>>
>> On 3/7/23 15:00, Costas Argyris wrote:
>> > Hi Jacek,
>> >
>> > "Is there a reason to make it specific to x86_64? It seems to me that
>> > all mingw hosts could use it."
>> >
>> > Are you referring to the 32-bit host?    My concern here is that this
>> > functionality (embedding the UTF-8
>> > manifest file into the executable) is only truly supported in recent
>> > versions of Windows.    From:
>> >
>> >
>> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
>> >
>> > It says that Windows Version 1903 (May 2019 Update) enables this, so
>> > we are looking at the 64-bit
>> > version of Windows.
>> >
>> > I suppose you are referring to the scenario where one has a 32-bit
>> > gcc + mingw running in a 64-bit
>> > Windows that is recent enough to support this?    It is not clear to
>> > me based on the above doc what
>> > would happen encoding-wise in that situation, and I haven't tried it
>> > either because I assumed that
>> > most people would want the 64-bit version of gcc since they are
>> > probably running a 64-bit OS.
>> >
>> > If you think it is useful, I could look into that as a separate task
>> > to try and keep this one simple, if
>> > that makes sense.
>>
>>
>> Yes, realistically it's mostly about 32-bit gcc on 64-bit Windows
>> (perhaps aarch64 as well at some point in the future). It's probably
>> indeed not very popular configuration those days, but I think it should
>> work just fine if you didn't explicitly limit the patch to x86_64.
>>
>>
>> > "I think that .manifest file should also be a dependency here."
>> >
>> > Why is that?    Windres takes only the .rc file as its input, as per
>> > its own doc, and it successfully
>> > compiles it into an object file.    The .manifest file is only
>> > referenced by the .rc file, and it doesn't
>> > get passed to windres, so I don't see why it has to be listed as a
>> > prerequisite in the make rule.
>>
>>
>> The point that when winnt-utf8.manifest is modified, utf8-mingw32.o
>> should be rebuilt. Anyway, it's probably not a big deal (I should
>> disclaim that I'm not very familiar with gcc build system; I'm mostly on
>> this ML due to mingw-w64 contributions).
>>
>>
>> Thanks,
>>
>> Jacek
>>
>>

[-- Attachment #2: 0001-Enable-UTF-8-code-page-on-Windows-64-bit-host-PR1088.patch --]
[-- Type: text/x-patch, Size: 6518 bytes --]

From 694d6f4860a08f690070df411f3f72d66a48a981 Mon Sep 17 00:00:00 2001
From: Costas Argyris <costas.argyris@gmail.com>
Date: Tue, 28 Feb 2023 17:10:18 +0000
Subject: [PATCH] Enable UTF-8 code page on Windows 64-bit host [PR108865]

Compile a resource object that contains the utf8 manifest.

Then link that object into the driver and compiler proper.

For compiler proper the link has to be forced because the
resource object file gets into a static library (libbackend.a)
and gets eventually dropped because it has no symbols of
its own and nothing is referencing it inside the library.

Therefore, an artificial symbol is planted to force the link.
---
 gcc/config.host                     |  5 ++-
 gcc/config/i386/sym-mingw32.cc      |  1 +
 gcc/config/i386/utf8-mingw32.rc     |  3 ++
 gcc/config/i386/winnt-utf8.manifest |  8 ++++
 gcc/config/i386/x-mingw32           |  3 +-
 gcc/config/i386/x-mingw32-utf8      | 57 +++++++++++++++++++++++++++++
 6 files changed, 73 insertions(+), 4 deletions(-)
 create mode 100644 gcc/config/i386/sym-mingw32.cc
 create mode 100644 gcc/config/i386/utf8-mingw32.rc
 create mode 100644 gcc/config/i386/winnt-utf8.manifest
 create mode 100644 gcc/config/i386/x-mingw32-utf8

diff --git a/gcc/config.host b/gcc/config.host
index a522c39658e..4abb32ad73d 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -241,10 +241,11 @@ case ${host} in
   x86_64-*-mingw*)
     use_long_long_for_widest_fast_int=yes
     host_xm_file=i386/xm-mingw32.h
-    host_xmake_file="${host_xmake_file} i386/x-mingw32"
+    host_xmake_file="${host_xmake_file} i386/x-mingw32 i386/x-mingw32-utf8"
     host_exeext=.exe
     out_host_hook_obj=host-mingw32.o
-    host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o"
+    host_extra_objs="${host_extra_objs} utf8-mingw32.o"
+    host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o utf8rc-mingw32.o"
     host_lto_plugin_soname=liblto_plugin.dll
     ;;
   aarch64*-*-darwin*)
diff --git a/gcc/config/i386/sym-mingw32.cc b/gcc/config/i386/sym-mingw32.cc
new file mode 100644
index 00000000000..f369698abc4
--- /dev/null
+++ b/gcc/config/i386/sym-mingw32.cc
@@ -0,0 +1 @@
+char HOST_EXTRA_OBJS_SYMBOL;
diff --git a/gcc/config/i386/utf8-mingw32.rc b/gcc/config/i386/utf8-mingw32.rc
new file mode 100644
index 00000000000..e2174e85b7c
--- /dev/null
+++ b/gcc/config/i386/utf8-mingw32.rc
@@ -0,0 +1,3 @@
+#include <winuser.h>
+
+CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "winnt-utf8.manifest"
diff --git a/gcc/config/i386/winnt-utf8.manifest b/gcc/config/i386/winnt-utf8.manifest
new file mode 100644
index 00000000000..dab929e1515
--- /dev/null
+++ b/gcc/config/i386/winnt-utf8.manifest
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
+  <application>
+    <windowsSettings>
+      <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
+    </windowsSettings>
+  </application>
+</assembly>
diff --git a/gcc/config/i386/x-mingw32 b/gcc/config/i386/x-mingw32
index 5b8b5f96143..cb3d8434881 100644
--- a/gcc/config/i386/x-mingw32
+++ b/gcc/config/i386/x-mingw32
@@ -27,8 +27,7 @@ WERROR_FLAGS += -Wno-format
 
 host-mingw32.o : $(srcdir)/config/i386/host-mingw32.cc $(CONFIG_H) $(SYSTEM_H) \
   coretypes.h hosthooks.h hosthooks-def.h toplev.h $(DIAGNOSTIC_H) $(HOOKS_H)
-	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-		$(srcdir)/config/i386/host-mingw32.cc
+	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<
 
 driver-mingw32.o : $(srcdir)/config/i386/driver-mingw32.cc $(CONFIG_H)
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<
diff --git a/gcc/config/i386/x-mingw32-utf8 b/gcc/config/i386/x-mingw32-utf8
new file mode 100644
index 00000000000..efeeeff4996
--- /dev/null
+++ b/gcc/config/i386/x-mingw32-utf8
@@ -0,0 +1,57 @@
+# Copyright (C) 2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+#
+#
+# For 64-bit Windows host, embed a manifest that sets the active
+# code page of the driver and compiler proper processes to utf8.
+# This only has an effect on Windows version 1903 (May 2019 Update)
+# or later.
+
+# The resource .rc file references the utf8 .manifest file.
+# Compile it into an object file using windres.
+# The resulting .o file gets added to host_extra_gcc_objs in
+# config.host for x86_64-*-mingw* host and gets linked into
+# the driver as a .o file, so it's lack of symbols is OK.
+utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc \
+  $(srcdir)/config/i386/winnt-utf8.manifest
+	$(WINDRES) $< $@
+
+# Create an object file that just exports the global symbol
+# HOST_EXTRA_OBJS_SYMBOL
+sym-mingw32.o : $(srcdir)/config/i386/sym-mingw32.cc
+	$(COMPILER) -c $< $@
+
+# Combine the two object files into one which has both the
+# compiled utf8 resource and the HOST_EXTRA_OBJS_SYMBOL symbol.
+# The resulting .o file gets added to host_extra_objs in
+# config.host for x86_64-*-mingw* host and gets archived into
+# libbackend.a which gets linked into the compiler proper.
+# If nothing references it into libbackend.a, it will not
+# get linked into the compiler proper eventually.
+# Therefore we need to request the symbol at compiler link time.
+utf8-mingw32.o : utf8rc-mingw32.o sym-mingw32.o
+	$(COMPILER) -r utf8rc-mingw32.o sym-mingw32.o -o $@
+
+# Force compilers to link against the utf8 resource by
+# requiring the symbol to be defined.
+# Otherwise the object file won't get linked in the compilers
+# because nothing is referencing it in libbackend.a
+# This is expected because the resource object is not supposed
+# to have any symbols, it just has to be linked into the
+# executable in order for Windows to use the utf8 code page.
+$(COMPILERS) : override LDFLAGS += -Wl,--require-defined=HOST_EXTRA_OBJS_SYMBOL
-- 
2.30.2

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Costas Argyris]

[-- Attachment #1.1: Type: text/plain, Size: 3677 bytes --]

Pinging the list and mingw maintainer.

Analysis and pre-approval here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865

On Wed, 8 Mar 2023 at 10:52, Costas Argyris <costas.argyris@gmail.com>
wrote:

> Added .manifest file to the make rule for utf8rc-mingw32.o, latest patch
> attached.
>
> On Tue, 7 Mar 2023 at 15:27, Costas Argyris <costas.argyris@gmail.com>
> wrote:
>
>> Hi Jacek,
>>
>> "but I think it should work just fine if you didn't explicitly limit the
>> patch to x86_64."
>>
>> I would think so too.
>>
>> Actually, even cygwin might benefit from this, assuming it has the same
>> problem, which I don't know if it's the case.
>>
>> But I'm not experienced with that so I would like to explore these hosts
>> separately and just focus on the most common 64-bit Windows host with this
>> change, if possible.
>>
>> "The point that when winnt-utf8.manifest is modified, utf8-mingw32.o
>> should be rebuilt."
>>
>> Right, makes sense.
>>
>> Just noting that winnt-utf8.manifest is really not meant to be modified,
>> because it is copied straight from:
>>
>>
>> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
>>
>> and will probably remain like that, but I do get your point and I am
>> happy to make the change.
>>
>> Thanks,
>> Costas
>>
>> On Tue, 7 Mar 2023 at 14:18, Jacek Caban <jacek@codeweavers.com> wrote:
>>
>>> Hi Costas,
>>>
>>> On 3/7/23 15:00, Costas Argyris wrote:
>>> > Hi Jacek,
>>> >
>>> > "Is there a reason to make it specific to x86_64? It seems to me that
>>> > all mingw hosts could use it."
>>> >
>>> > Are you referring to the 32-bit host?    My concern here is that this
>>> > functionality (embedding the UTF-8
>>> > manifest file into the executable) is only truly supported in recent
>>> > versions of Windows.    From:
>>> >
>>> >
>>> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
>>> >
>>> > It says that Windows Version 1903 (May 2019 Update) enables this, so
>>> > we are looking at the 64-bit
>>> > version of Windows.
>>> >
>>> > I suppose you are referring to the scenario where one has a 32-bit
>>> > gcc + mingw running in a 64-bit
>>> > Windows that is recent enough to support this?    It is not clear to
>>> > me based on the above doc what
>>> > would happen encoding-wise in that situation, and I haven't tried it
>>> > either because I assumed that
>>> > most people would want the 64-bit version of gcc since they are
>>> > probably running a 64-bit OS.
>>> >
>>> > If you think it is useful, I could look into that as a separate task
>>> > to try and keep this one simple, if
>>> > that makes sense.
>>>
>>>
>>> Yes, realistically it's mostly about 32-bit gcc on 64-bit Windows
>>> (perhaps aarch64 as well at some point in the future). It's probably
>>> indeed not very popular configuration those days, but I think it should
>>> work just fine if you didn't explicitly limit the patch to x86_64.
>>>
>>>
>>> > "I think that .manifest file should also be a dependency here."
>>> >
>>> > Why is that?    Windres takes only the .rc file as its input, as per
>>> > its own doc, and it successfully
>>> > compiles it into an object file.    The .manifest file is only
>>> > referenced by the .rc file, and it doesn't
>>> > get passed to windres, so I don't see why it has to be listed as a
>>> > prerequisite in the make rule.
>>>
>>>
>>> The point that when winnt-utf8.manifest is modified, utf8-mingw32.o
>>> should be rebuilt. Anyway, it's probably not a big deal (I should
>>> disclaim that I'm not very familiar with gcc build system; I'm mostly on
>>> this ML due to mingw-w64 contributions).
>>>
>>>
>>> Thanks,
>>>
>>> Jacek
>>>
>>>

[-- Attachment #2: 0001-Enable-UTF-8-code-page-on-Windows-64-bit-host-PR1088.patch --]
[-- Type: text/x-patch, Size: 6518 bytes --]

From 694d6f4860a08f690070df411f3f72d66a48a981 Mon Sep 17 00:00:00 2001
From: Costas Argyris <costas.argyris@gmail.com>
Date: Tue, 28 Feb 2023 17:10:18 +0000
Subject: [PATCH] Enable UTF-8 code page on Windows 64-bit host [PR108865]

Compile a resource object that contains the utf8 manifest.

Then link that object into the driver and compiler proper.

For compiler proper the link has to be forced because the
resource object file gets into a static library (libbackend.a)
and gets eventually dropped because it has no symbols of
its own and nothing is referencing it inside the library.

Therefore, an artificial symbol is planted to force the link.
---
 gcc/config.host                     |  5 ++-
 gcc/config/i386/sym-mingw32.cc      |  1 +
 gcc/config/i386/utf8-mingw32.rc     |  3 ++
 gcc/config/i386/winnt-utf8.manifest |  8 ++++
 gcc/config/i386/x-mingw32           |  3 +-
 gcc/config/i386/x-mingw32-utf8      | 57 +++++++++++++++++++++++++++++
 6 files changed, 73 insertions(+), 4 deletions(-)
 create mode 100644 gcc/config/i386/sym-mingw32.cc
 create mode 100644 gcc/config/i386/utf8-mingw32.rc
 create mode 100644 gcc/config/i386/winnt-utf8.manifest
 create mode 100644 gcc/config/i386/x-mingw32-utf8

diff --git a/gcc/config.host b/gcc/config.host
index a522c39658e..4abb32ad73d 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -241,10 +241,11 @@ case ${host} in
   x86_64-*-mingw*)
     use_long_long_for_widest_fast_int=yes
     host_xm_file=i386/xm-mingw32.h
-    host_xmake_file="${host_xmake_file} i386/x-mingw32"
+    host_xmake_file="${host_xmake_file} i386/x-mingw32 i386/x-mingw32-utf8"
     host_exeext=.exe
     out_host_hook_obj=host-mingw32.o
-    host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o"
+    host_extra_objs="${host_extra_objs} utf8-mingw32.o"
+    host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o utf8rc-mingw32.o"
     host_lto_plugin_soname=liblto_plugin.dll
     ;;
   aarch64*-*-darwin*)
diff --git a/gcc/config/i386/sym-mingw32.cc b/gcc/config/i386/sym-mingw32.cc
new file mode 100644
index 00000000000..f369698abc4
--- /dev/null
+++ b/gcc/config/i386/sym-mingw32.cc
@@ -0,0 +1 @@
+char HOST_EXTRA_OBJS_SYMBOL;
diff --git a/gcc/config/i386/utf8-mingw32.rc b/gcc/config/i386/utf8-mingw32.rc
new file mode 100644
index 00000000000..e2174e85b7c
--- /dev/null
+++ b/gcc/config/i386/utf8-mingw32.rc
@@ -0,0 +1,3 @@
+#include <winuser.h>
+
+CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "winnt-utf8.manifest"
diff --git a/gcc/config/i386/winnt-utf8.manifest b/gcc/config/i386/winnt-utf8.manifest
new file mode 100644
index 00000000000..dab929e1515
--- /dev/null
+++ b/gcc/config/i386/winnt-utf8.manifest
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
+  <application>
+    <windowsSettings>
+      <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
+    </windowsSettings>
+  </application>
+</assembly>
diff --git a/gcc/config/i386/x-mingw32 b/gcc/config/i386/x-mingw32
index 5b8b5f96143..cb3d8434881 100644
--- a/gcc/config/i386/x-mingw32
+++ b/gcc/config/i386/x-mingw32
@@ -27,8 +27,7 @@ WERROR_FLAGS += -Wno-format
 
 host-mingw32.o : $(srcdir)/config/i386/host-mingw32.cc $(CONFIG_H) $(SYSTEM_H) \
   coretypes.h hosthooks.h hosthooks-def.h toplev.h $(DIAGNOSTIC_H) $(HOOKS_H)
-	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-		$(srcdir)/config/i386/host-mingw32.cc
+	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<
 
 driver-mingw32.o : $(srcdir)/config/i386/driver-mingw32.cc $(CONFIG_H)
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<
diff --git a/gcc/config/i386/x-mingw32-utf8 b/gcc/config/i386/x-mingw32-utf8
new file mode 100644
index 00000000000..efeeeff4996
--- /dev/null
+++ b/gcc/config/i386/x-mingw32-utf8
@@ -0,0 +1,57 @@
+# Copyright (C) 2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+#
+#
+# For 64-bit Windows host, embed a manifest that sets the active
+# code page of the driver and compiler proper processes to utf8.
+# This only has an effect on Windows version 1903 (May 2019 Update)
+# or later.
+
+# The resource .rc file references the utf8 .manifest file.
+# Compile it into an object file using windres.
+# The resulting .o file gets added to host_extra_gcc_objs in
+# config.host for x86_64-*-mingw* host and gets linked into
+# the driver as a .o file, so it's lack of symbols is OK.
+utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc \
+  $(srcdir)/config/i386/winnt-utf8.manifest
+	$(WINDRES) $< $@
+
+# Create an object file that just exports the global symbol
+# HOST_EXTRA_OBJS_SYMBOL
+sym-mingw32.o : $(srcdir)/config/i386/sym-mingw32.cc
+	$(COMPILER) -c $< $@
+
+# Combine the two object files into one which has both the
+# compiled utf8 resource and the HOST_EXTRA_OBJS_SYMBOL symbol.
+# The resulting .o file gets added to host_extra_objs in
+# config.host for x86_64-*-mingw* host and gets archived into
+# libbackend.a which gets linked into the compiler proper.
+# If nothing references it into libbackend.a, it will not
+# get linked into the compiler proper eventually.
+# Therefore we need to request the symbol at compiler link time.
+utf8-mingw32.o : utf8rc-mingw32.o sym-mingw32.o
+	$(COMPILER) -r utf8rc-mingw32.o sym-mingw32.o -o $@
+
+# Force compilers to link against the utf8 resource by
+# requiring the symbol to be defined.
+# Otherwise the object file won't get linked in the compilers
+# because nothing is referencing it in libbackend.a
+# This is expected because the resource object is not supposed
+# to have any symbols, it just has to be linked into the
+# executable in order for Windows to use the utf8 code page.
+$(COMPILERS) : override LDFLAGS += -Wl,--require-defined=HOST_EXTRA_OBJS_SYMBOL
-- 
2.30.2

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Jonathan Yong]

On 3/9/23 13:33, Costas Argyris wrote:
> Pinging the list and mingw maintainer.
> 
> Analysis and pre-approval here:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
> 

Thanks, pushed to master branch.

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Costas Argyris]

[-- Attachment #1.1: Type: text/plain, Size: 1257 bytes --]

The patch attached to this email extends the UTF-8 support of the
driver and compiler processes to the 32-bit mingw host.    Initially,
only the 64-bit host got it.

About the changes in sym-mingw32.cc:

Even though the 64-bit host was building fine with the symbol being
simply declared as a char, the 32-bit host was failing to find the
symbol at link time because a leading underscore was being added
to it by the compiler.    The asm keyword ensures that the symbol
always appears with that exact name, such that the linker will
always find it.

The patch also includes Jacek's flag about adding the .manifest file
as a prerequisite for the object file (this was actually done from before
but an earlier version of the patch was pushed so it was missed).

Tested building from master for both 32 and 64-bit mingw hosts using:

1) cross-compilation from a Debian machine using configure + make
2) native-compilation from a Windows machine using MSYS2

On Thu, 9 Mar 2023 at 15:03, Jonathan Yong <10walls@gmail.com> wrote:

> On 3/9/23 13:33, Costas Argyris wrote:
> > Pinging the list and mingw maintainer.
> >
> > Analysis and pre-approval here:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
> >
>
> Thanks, pushed to master branch.
>
>
>

[-- Attachment #2: 0001-Extend-UTF-8-support-to-the-32-bit-mingw-host.patch --]
[-- Type: text/x-patch, Size: 2373 bytes --]

From 0ed08739f44116eaef46b552df923959ba945afa Mon Sep 17 00:00:00 2001
From: Costas Argyris <costas.argyris@gmail.com>
Date: Sun, 26 Mar 2023 11:32:13 +0100
Subject: [PATCH] Extend UTF-8 support to the 32-bit mingw host.

Prevent any name mangling in HOST_EXTRA_OBJS_SYMBOL
such that the linker always finds it by that name.

Also add the .manifest file as an explicit
dependency in the make rule such that the
object gets re-built if it changes.
---
 gcc/config.host                | 5 +++--
 gcc/config/i386/sym-mingw32.cc | 4 +++-
 gcc/config/i386/x-mingw32-utf8 | 3 ++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/gcc/config.host b/gcc/config.host
index 4abb32ad73d..5df85752ed4 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -232,10 +232,11 @@ case ${host} in
     ;;
   i[34567]86-*-mingw32*)
     host_xm_file=i386/xm-mingw32.h
-    host_xmake_file="${host_xmake_file} i386/x-mingw32"
+    host_xmake_file="${host_xmake_file} i386/x-mingw32 i386/x-mingw32-utf8"
     host_exeext=.exe
     out_host_hook_obj=host-mingw32.o
-    host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o"
+    host_extra_objs="${host_extra_objs} utf8-mingw32.o"
+    host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o utf8rc-mingw32.o"
     host_lto_plugin_soname=liblto_plugin.dll
     ;;
   x86_64-*-mingw*)
diff --git a/gcc/config/i386/sym-mingw32.cc b/gcc/config/i386/sym-mingw32.cc
index f369698abc4..2f8dee6c1ec 100644
--- a/gcc/config/i386/sym-mingw32.cc
+++ b/gcc/config/i386/sym-mingw32.cc
@@ -1 +1,3 @@
-char HOST_EXTRA_OBJS_SYMBOL;
+/* Prevent any name mangling to make sure that the linker
+   will always find the symbol. */
+char HOST_EXTRA_OBJS_SYMBOL asm ("HOST_EXTRA_OBJS_SYMBOL");
diff --git a/gcc/config/i386/x-mingw32-utf8 b/gcc/config/i386/x-mingw32-utf8
index 9de963d7965..cf5c3db3d8b 100644
--- a/gcc/config/i386/x-mingw32-utf8
+++ b/gcc/config/i386/x-mingw32-utf8
@@ -27,7 +27,8 @@
 # The resulting .o file gets added to host_extra_gcc_objs in
 # config.host for x86_64-*-mingw* host and gets linked into
 # the driver as a .o file, so it's lack of symbols is OK.
-utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc
+utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc \
+  $(srcdir)/config/i386/winnt-utf8.manifest
 	$(WINDRES) $< $@
 
 # Create an object file that just exports the global symbol
-- 
2.30.2

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Jonathan Yong]

On 3/27/23 17:17, Costas Argyris wrote:
> The patch attached to this email extends the UTF-8 support of the
> driver and compiler processes to the 32-bit mingw host.    Initially,
> only the 64-bit host got it.
> 
> About the changes in sym-mingw32.cc:
> 
> Even though the 64-bit host was building fine with the symbol being
> simply declared as a char, the 32-bit host was failing to find the
> symbol at link time because a leading underscore was being added
> to it by the compiler.    The asm keyword ensures that the symbol
> always appears with that exact name, such that the linker will
> always find it.
> 
> The patch also includes Jacek's flag about adding the .manifest file
> as a prerequisite for the object file (this was actually done from before
> but an earlier version of the patch was pushed so it was missed).
> 
> Tested building from master for both 32 and 64-bit mingw hosts using:
> 
> 1) cross-compilation from a Debian machine using configure + make
> 2) native-compilation from a Windows machine using MSYS2
> 
Thanks, approved and pushed to master branch.

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Costas Argyris]

[-- Attachment #1.1: Type: text/plain, Size: 1329 bytes --]

I forgot to update the relevant comments with the previous patch.

This is a comment-only patch that brings them up-to-date.

On Tue, 28 Mar 2023 at 09:05, Jonathan Yong <10walls@gmail.com> wrote:

> On 3/27/23 17:17, Costas Argyris wrote:
> > The patch attached to this email extends the UTF-8 support of the
> > driver and compiler processes to the 32-bit mingw host.    Initially,
> > only the 64-bit host got it.
> >
> > About the changes in sym-mingw32.cc:
> >
> > Even though the 64-bit host was building fine with the symbol being
> > simply declared as a char, the 32-bit host was failing to find the
> > symbol at link time because a leading underscore was being added
> > to it by the compiler.    The asm keyword ensures that the symbol
> > always appears with that exact name, such that the linker will
> > always find it.
> >
> > The patch also includes Jacek's flag about adding the .manifest file
> > as a prerequisite for the object file (this was actually done from before
> > but an earlier version of the patch was pushed so it was missed).
> >
> > Tested building from master for both 32 and 64-bit mingw hosts using:
> >
> > 1) cross-compilation from a Debian machine using configure + make
> > 2) native-compilation from a Windows machine using MSYS2
> >
> Thanks, approved and pushed to master branch.
>
>

[-- Attachment #2: 0001-mingw-Fix-comments-in-x-mingw32-utf8.patch --]
[-- Type: text/x-patch, Size: 2587 bytes --]

From 87da0323ec5b08d44f17713d8d4e19664d7a3aa6 Mon Sep 17 00:00:00 2001
From: Costas Argyris <costas.argyris@gmail.com>
Date: Tue, 28 Mar 2023 11:29:06 +0100
Subject: [PATCH] mingw: Fix comments in x-mingw32-utf8

This is a comment-only change that I should have
done with the previous commit (304c7d44a) but
forgot to do so.
---
 gcc/config/i386/x-mingw32-utf8 | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/gcc/config/i386/x-mingw32-utf8 b/gcc/config/i386/x-mingw32-utf8
index cf5c3db3d8b..2783dd259a6 100644
--- a/gcc/config/i386/x-mingw32-utf8
+++ b/gcc/config/i386/x-mingw32-utf8
@@ -17,15 +17,15 @@
 # <http://www.gnu.org/licenses/>.
 #
 #
-# For 64-bit Windows host, embed a manifest that sets the active
+# For mingw Windows hosts, embed a manifest that sets the active
 # code page of the driver and compiler proper processes to utf8.
-# This only has an effect on Windows version 1903 (May 2019 Update)
-# or later.
+# This only has an effect when gcc is hosted on Windows version
+# 1903 (May 2019 Update) or later.
 
 # The resource .rc file references the utf8 .manifest file.
 # Compile it into an object file using windres.
 # The resulting .o file gets added to host_extra_gcc_objs in
-# config.host for x86_64-*-mingw* host and gets linked into
+# config.host for mingw hosts and gets linked into
 # the driver as a .o file, so it's lack of symbols is OK.
 utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc \
   $(srcdir)/config/i386/winnt-utf8.manifest
@@ -39,7 +39,7 @@ sym-mingw32.o : $(srcdir)/config/i386/sym-mingw32.cc
 # Combine the two object files into one which has both the
 # compiled utf8 resource and the HOST_EXTRA_OBJS_SYMBOL symbol.
 # The resulting .o file gets added to host_extra_objs in
-# config.host for x86_64-*-mingw* host and gets archived into
+# config.host for mingw hosts and gets archived into
 # libbackend.a which gets linked into the compiler proper.
 # If nothing references it into libbackend.a, it will not
 # get linked into the compiler proper eventually.
@@ -54,4 +54,8 @@ utf8-mingw32.o : utf8rc-mingw32.o sym-mingw32.o
 # This is expected because the resource object is not supposed
 # to have any symbols, it just has to be linked into the
 # executable in order for Windows to use the utf8 code page.
+# Some build environments are passing these flags to other
+# programs as well, so make the symbol definition optional
+# such that these programs don't fail to build when they
+# don't find it.
 $(COMPILERS) : override LDFLAGS += -Wl,--undefined=HOST_EXTRA_OBJS_SYMBOL
-- 
2.30.2

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

[Jonathan Yong]

On 3/28/23 10:43, Costas Argyris wrote:
> I forgot to update the relevant comments with the previous patch.
> 
> This is a comment-only patch that brings them up-to-date.
> 

Done, thanks.