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
