https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #47 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Yong
:
https://gcc.gnu.org/g:19da6d2d0048eb6a260a5cf8af707cb455848bfb
commit r13-8107-g19da6d2d0048eb6a260a5cf8af707cb455848bfb
Author: Costas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #46 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:4f1ebd54380e16927cd0085be939165870354eac
commit r14-5768-g4f1ebd54380e16927cd0085be939165870354eac
Author: Costas Argyris
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #45 from Costas Argyris ---
Created attachment 56653
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56653=edit
Introduce configure option --disable-win32-utf8-manifest
Thanks for the pointers.
I attach a patch that disables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #43 from Eric Botcazou ---
> Looks like what is being requested here is a windows-host-specific
> configuration option similar to the existing --disable-win32-registry, like
> for example --disable-win32-utf8-manifest with its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #42 from Costas Argyris ---
Looks like what is being requested here is a windows-host-specific
configuration option similar to the existing --disable-win32-registry, like for
example --disable-win32-utf8-manifest with its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #41 from Eric Botcazou ---
> I'm curious though: How come it took so long to report this one?Is this
> a rarely-used feature of the Ada compiler?It seems strange that a
> feature of the compiler would interact so strongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #40 from Costas Argyris ---
(In reply to Eric Botcazou from comment #39)
> FWIW this also breaks the GNAT_CODE_PAGE feature of the Ada compiler (which
> is arguably a kludge) so providing a configure option to revert to the old
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #38 from LIU Hao ---
(In reply to Andrew Pinski from comment #35)
> (In reply to peter0x44 from comment #34)
> > Unfortunately, this option breaks GCC running under Windows XP.
>
> XP has not been supported by mingw for a long time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #37 from peter0x44 at disroot dot org ---
Sorry, comment got sent by accident, before I was done typing.
And you replied before I finished, too.
Thanks for pointing me in the correct direction.
===
IRRELEVANT
Executables with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #36 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #35)
> (In reply to peter0x44 from comment #34)
> > Unfortunately, this option breaks GCC running under Windows XP.
>
> XP has not been supported by mingw for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #35 from Andrew Pinski ---
(In reply to peter0x44 from comment #34)
> Unfortunately, this option breaks GCC running under Windows XP.
XP has not been supported by mingw for a long time so I have no idea how you
have been building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
peter0x44 at disroot dot org changed:
What|Removed |Added
CC||peter0x44 at disroot dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #33 from Costas Argyris ---
It should be noted that with the current implementation, windres (part of
binutils) is mandatory when building for the mingw (Windows) hosts, both 32 and
64-bit versions.
That is, a build failure will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #32 from Costas Argyris ---
Followed by:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e70e36cbef4f01e7d32bafe17698c3bf3e4624b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #31 from Costas Argyris ---
This was initially done only for the 64-bit mingw Windows host
(x86_64-*-mingw*).
This is the patch that extended it to the 32-bit version as well
(i[34567]86-*-mingw32*):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Richard Biener changed:
What|Removed |Added
CC||jdx at o2 dot pl
--- Comment #30 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #29 from Costas Argyris ---
patch that makes symbol optional was pushed to master:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=08ef17c75777ef9e4e7ead132ccd7a6d03ae6020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Costas Argyris changed:
What|Removed |Added
Target|x86_64-w64-mingw32 |
--- Comment #28 from Costas Argyris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #27 from Costas Argyris ---
Good to hear.
FYI, the driver programs (gcc.exe and g++.exe) should also have it (they do in
my builds, both native and cross).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #26 from LIU Hao ---
(In reply to Costas Argyris from comment #23)
> Created attachment 54730 [details]
> Make symbol optional
>
> Could you please try this patch?
Works for me. I have checked that cpp.exe, cc1.exe, cc1plus.exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #25 from Costas Argyris ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #24 from LIU Hao ---
(In reply to Costas Argyris from comment #23)
> Created attachment 54730 [details]
> Make symbol optional
>
> Could you please try this patch?
Didn't test this completely, but it did allow the build to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #23 from Costas Argyris ---
Created attachment 54730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54730=edit
Make symbol optional
Could you please try this patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #22 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:d11e088210a551235d3937f867ee1c8b19d02290
commit r13-6552-gd11e088210a551235d3937f867ee1c8b19d02290
Author: Costas Argyris
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Costas Argyris changed:
What|Removed |Added
Attachment #54589|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #18 from Andrew Pinski ---
(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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Costas Argyris changed:
What|Removed |Added
Attachment #54559|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #16 from Andrew Pinski ---
(In reply to Costas Argyris from comment #15)
> Sounds like I am hitting a separate existing limitation that has nothing to
> do with this bug.
>
> Do we need a new bug report for that one then?
No one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #15 from Costas Argyris ---
Sounds like I am hitting a separate existing limitation that has nothing to do
with this bug.
Do we need a new bug report for that one then?
FWIW, gcc/config.host wasn't doing anything with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #14 from Andrew Pinski ---
So the problem is host_extra_objs gets included in libbackend.a but since
nothing references it inside the static library, it does not get linked into
the cc1 ...
Looks like other changes are needed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #13 from Costas Argyris ---
With the changes in the attached patch, the utf8 object file gets linked into
gcc.exe but not cc1.exe - How can I achieve this?Basically this object file
has to be linked pretty much in every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #12 from Costas Argyris ---
Sent email to binutils about possible windres issue/limitation:
https://sourceware.org/pipermail/binutils/2023-March/126361.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #11 from Costas Argyris ---
Capturing another data point:
I hex-compared an executable before and after applying the UTF-8 manifest with
mt.exe just to try and see what it does, and I noticed a few things:
1) The executable size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #10 from Costas Argyris ---
The only interesting bit I found there was the shell script that gets called
before actually running windres:
https://github.com/jbruchon/jdupes/blob/master/Makefile#L201
which is doing some setup:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #9 from Andrew Pinski ---
https://github.com/jbruchon/jdupes
Suggest this is definitely possible. That program includes a manifest that say
that the program supports long file names.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #8 from Andrew Pinski ---
(In reply to Costas Argyris from comment #7)
> I couldn't find examples online for doing this.There are examples of
> compiling and linking resource files in general using GNU tools, but not a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #7 from Costas Argyris ---
I think the problem is that the embedding of the manifest into the executable
is a very low-level process that depends on ms specifics that mt.exe (or VS)
knows about and windres + link doesn't.
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #6 from Costas Argyris ---
Created attachment 54559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54559=edit
Integrate UTF-8 manifest into gcc's build process for mingw host
This builds fine and the resource object does get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #4 from Costas Argyris ---
Using the manifest approach described in:
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
it is possible to convert a full existing gcc + mingw-w64 toolchain (all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #3 from Andrew Pinski ---
(In reply to Costas Argyris from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Utf8 is the best generic solution really.
> > Using wmain is not very portable and the rest of gcc's sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #2 from Costas Argyris ---
(In reply to Andrew Pinski from comment #1)
> Utf8 is the best generic solution really.
> Using wmain is not very portable and the rest of gcc's sources can't use
> wchar_t as that would break unix/Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #1 from Andrew Pinski ---
Utf8 is the best generic solution really.
Using wmain is not very portable and the rest of gcc's sources can't use
wchar_t as that would break unix/Linux handling.
47 matches
Mail list logo
