https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #14 from Costas Argyris ---
(In reply to Eric Botcazou from comment #13)
> Thanks for the fix. Now it needs to be backported onto the 13 branch.
Just sent email about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #12 from Costas Argyris ---
I think this can be considered as fixed now, since the new
--disable-win32-utf8-manifest configure option leaves out the utf8 manifest and
you shouldn't have a problem running gcc even on XP if you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #10 from Costas Argyris ---
> I suspect there should be an `AC_ARG_ENABLE` in configure.ac?
It doesn't appear to be necessary to me.It also wasn't part of the advice
of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865#c44 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #8 from Costas Argyris ---
(In reply to LIU Hao from comment #3)
> Costas, would you like to provide a configure option to exclude that
> manifest?
I created a patch for that and attached it here:
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=70
--- Comment #7 from Costas Argyris ---
Some ideas on how this could be implemented in case someone wants to try and
fix this sooner than me:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865#c42
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 #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=70
--- Comment #6 from Costas Argyris ---
I see.
I can try to come up with a patch to add a windows-host-specific configure
option to exclude the utf8 manifest on demand, but I won't be able to work on
this for a while...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #4 from Costas Argyris ---
A couple of comments:
1) Isn't Windows XP officially not supported any more?If that is the case,
does it make sense to introduce a new configure option solely to deal with an
unsupported host?I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #13 from Costas Argyris ---
(In reply to John Soo from comment #12)
> I think the general problem in that issue is that ARG_MAX is not respected
> when the driver (or any subprocess) execs things on linux. I think that it
> is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #11 from Costas Argyris ---
(In reply to John Soo from comment #10)
> I'm also not sure
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;
> h=180ebb8a24d24fc5b105f2257d6216f6dfde62df fixes the collect bug because
> collect uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #7 from Costas Argyris ---
(In reply to John Soo from comment #6)
> This is not a Windows-only bug, so I don't think it is fixed.
Althought it is not mentioned explicitly in the title of this PR, the original
reporter did describe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244
--- Comment #6 from Costas Argyris ---
> I can't embed a UTF-8 manifest in my DLL and much less in my .a. As a
> library writer (I'm the QtCore maintainer), that's out of my hands - it is
> an application decision.
At this point I just meant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
Costas Argyris changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
--- Comment #6 from Costas Argyris ---
Part of this may be because the driver::finalize function introduced here:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9376dd63e6a2d94823f6faf8212c9f37bef5a656
is not called from main:
int
main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
--- Comment #7 from Costas Argyris ---
Implemented what Andrew said:
"I suspect we should expand the @file and then put it in a temp file and do the
correct thing."
Attached patch here but also sending to gcc-patches ML.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
--- Comment #9 from Costas Argyris ---
Fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df
Also this is windows-host-specific (Host field in the PR is empty).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
--- Comment #8 from Costas Argyris ---
Not likely to be fixed, so if someone stumbles upon this and needs a
workaround, you need to override the default specs as in the example above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #36 from Costas Argyris ---
Regarding usage of the -r flag:
Building windows(mingw)-hosted gcc with clang at this point seems highly
experimental at best, and impossible with msvc.
With clang (lld linker), -r is supported with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #34 from Costas Argyris ---
Hi Huaqi,
Patch has been pushed to master, you should now be able to get the latest gcc
sources and build without having to apply it manually.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #31 from Costas Argyris ---
(In reply to Tobias Burnus from comment #30)
> I see commit r13-7153-g3beeebd6934654f3453209730b98c7a1fd0305b6
> "mingw: Support building with older gcc versions"
>
> And I see in the associated email to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Costas Argyris changed:
What|Removed |Added
Attachment #54838|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #28 from Costas Argyris ---
I am not aware of any cases of building windows-hosted gcc with msvc or clang.
If the combination -r -nostdlib fixes this case without breaking all the others
that don't need -nostdlib (which sounds like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #24 from Costas Argyris ---
So this is because of the old (7.3) gcc version not supporting -r.
Indeed, in the 7.3 doc
https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Link-Options.html#Link-Options
there is no '-r' option while there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #18 from Costas Argyris ---
For some reason you are compiling gcc/utf8-mingw32.o as an executable, which
shouldn't be happening.
This is the rule for it in gcc\gcc\config\i386\x-mingw32-utf8
utf8-mingw32.o : utf8rc-mingw32.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #16 from Costas Argyris ---
Created attachment 54838
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54838=edit
Improve make rule for sym-mingw32.o
Could you please apply this patch after you get the latest gcc sources and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #14 from Costas Argyris ---
What is the version of the cross-compiler, cross-binutils and make that you are
using to build gcc for windows from linux?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #11 from Costas Argyris ---
As I said before, I think adding the "-o" flag to
$(COMPILER) -c $< -o $@
is a good and harmless change, but, as per your own report, it didn't solve
your issues because you still got that mysterious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #10 from Costas Argyris ---
Hi Huaqi,
This is building a larger project, which gcc is part of.I am not familiar
with that larger project and I have never built it.
Could we extract only the gcc-specific part out of the entire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #8 from Costas Argyris ---
Are you building the cross-compiler itself or just using an existing
cross-compiler to build for the windows host?
You may have to build the cross-compiler first from the latest gcc sources, and
then use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #7 from Costas Argyris ---
Still can't do much without detailed info on how exactly you are building gcc,
what is your build setup, what is your cross-compiler version, OS, how you
configure etc etc...Ideally, solid reproduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #5 from Costas Argyris ---
>> Yes, because -o is missing.
I don't understand why -o missing is a problem some times but not others
(because this has been succesfully built before with -o missing).
Adding a "-o" flag seems OK to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #3 from Costas Argyris ---
"The missing -o looks genuine, does not it?"
Not to me because this has been built successfully before.If this was the
problem then it would never build, right?
What happened in this case was that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #1 from Costas Argyris ---
Can you give some more info on how exactly you are cross-building gcc for
windows host?
Did you add the -fno-PIE flag manually or was it part of the build process you
are following?
Seems like you are
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
--- 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=109188
--- Comment #15 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=109188
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
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 #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 #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
Costas Argyris changed:
What|Removed |Added
Attachment #54589|0 |1
is obsolete|
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=71850
--- Comment #7 from Costas Argyris ---
Created attachment 54575
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54575=edit
Treat include path args the same way between cpp_unique_options and asm_options
The proposed patch extends the logic
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 #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 #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
--- 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 #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
Bug ID: 108865
Summary: gcc on Windows fails with Unicode path to source file
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107007
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
65 matches
Mail list logo
