https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #25 from James McKelvey ---
I just tried the latest snapshot and it works great, no need to specify
--disable-multilib.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #23 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:e3f8dfcd885d19d322b10fb4e36d50b60da2576b
commit r13-6578-ge3f8dfcd885d19d322b10fb4e36d50b60da2576b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #22 from Jakub Jelinek ---
Created attachment 54502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54502=edit
gcc13-pr107998.patch
Let's go with this patch then? Note, I can't really test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #21 from Jakub Jelinek ---
If so, then I don't understand why does t-cygwin-w64 exist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #20 from jon_y <10walls at gmail dot com> ---
No, Cygwin does not use fat objects/archives. As far as I know, Cygwin never
shipped multilib capable gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #19 from Jakub Jelinek ---
I don't know either. Maybe objdump would print something.
Anyway, looking at config-ml.in, it seems like the empty directory name would
basically
disable that multilib:
multidirs=
for i in `${CC-gcc}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #18 from James McKelvey ---
I don't know. How do I tell? I'm pretty sure they are just 64-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #17 from Jakub Jelinek ---
And those are libraries containing 64-bit objects, 32-bit objects, mixture of
that (FAT objects)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #16 from James McKelvey ---
$ find /usr/local/lib/gcc -name libgcc_s\*.dll -o -name libgcc.a
/usr/local/lib/gcc/x86_64-pc-cygwin/11.3.1/libgcc.a
/usr/local/lib/gcc/x86_64-pc-cygwin/12.1.1/libgcc.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #15 from Jakub Jelinek ---
(In reply to James McKelvey from comment #14)
> Okay I installed gcc-12, built about 10/29/2022:
>
> $ g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #14 from James McKelvey ---
Okay I installed gcc-12, built about 10/29/2022:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/12.2.1/lto-wrapper.exe
Target: x86_64-pc-cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #13 from Jakub Jelinek ---
I have tried a cross with the genmultilib exit 1 commented out, and the
difference between the previous state of just MULTILIB_DIRNAMES = 64 and 64 32
is
--- multilib.h 2023-02-01 18:41:31.013661359 +0100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #11 from James McKelvey ---
(In reply to Christophe Lyon from comment #10)
> Can you try to revert my patches:
> f0d3b6e384a68f8b58bc750f240a15cad92600cd
> ccb9c7b129206209cfc315ab1a0432b5f517bdd9
> and remove your patch at comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #10 from Christophe Lyon ---
Can you try to revert my patches:
f0d3b6e384a68f8b58bc750f240a15cad92600cd
ccb9c7b129206209cfc315ab1a0432b5f517bdd9
and remove your patch at comment #5 ?
You should still see the problem you reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #8 from James McKelvey ---
Okay I backed out the fix to t-cygwin-w64 and tried to build again with
--disable-multilib and stil got the "no dirname" error. So that fix is
definitely needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #7 from James McKelvey ---
That fix let the build proceed until it hit a #error much later. See 108011.
Cygwin seems to be removing support for 32-bit, so although multilib has built
for years, it won't anymore. That's my take.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #6 from Christophe Lyon ---
(In reply to James McKelvey from comment #5)
> This works:
>
> $ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64
> 2c2
> < MULTILIB_DIRNAMES = 64
> ---
> > MULTILIB_DIRNAMES = 64 32
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #5 from James McKelvey ---
This works:
$ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64
2c2
< MULTILIB_DIRNAMES = 64
---
> MULTILIB_DIRNAMES = 64 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #4 from Christophe Lyon ---
Indeed my patch aimed at catching such inconsistencies.
I guess before that the build had a 'strange' behavior? (with a missing
dirname, some parts of the shell genmultilib shell script would expand into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Component|bootstrap
23 matches
Mail list logo
