* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
@ 2022-05-17 18:28 ` reiter.christoph at gmail dot com
2022-05-18 19:47 ` reiter.christoph at gmail dot com
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: reiter.christoph at gmail dot com @ 2022-05-17 18:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #1 from Christoph Reiter <reiter.christoph at gmail dot com> ---
I've bisected it now:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=76f9c7f44fffb0b03266730b137313fe79f1c99e
76f9c7f44fffb0b03266730b137313fe79f1c99e is the first bad commit
commit 76f9c7f44fffb0b03266730b137313fe79f1c99e
Author: Bob Duff <duff@adacore.com>
Date: Wed Feb 3 05:31:16 2021 -0500
[Ada] Variable-sized node types
167 files changed, 18305 insertions(+), 43812 deletions(-)
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
2022-05-17 18:28 ` [Bug ada/105507] " reiter.christoph at gmail dot com
@ 2022-05-18 19:47 ` reiter.christoph at gmail dot com
2022-05-18 20:09 ` ebotcazou at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: reiter.christoph at gmail dot com @ 2022-05-18 19:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #2 from Christoph Reiter <reiter.christoph at gmail dot com> ---
Stack trace (I rebuilt the host gcc 11.3.0 with debug symbols and re-ran the
failing command with "-wrapper gdb,--args"):
Thread 1 received signal SIGSEGV, Segmentation fault.
0x7563bd90 in strlen () from C:\WINDOWS\SysWOW64\msvcrt.dll
(gdb) bt
#0 0x7563bd90 in strlen () from C:\WINDOWS\SysWOW64\msvcrt.dll
#1 0x01731831 in libiberty_vprintf_buffer_size (
format=format@entry=0x1a3f865 <gt_ggc_r_gt_ada_decl_h+517> "%s:%d",
args=<optimized out>, args@entry=0x1367df64 "")
at ../../gcc-11.3.0/libiberty/vprintf-support.c:105
#2 0x0173160a in xvasprintf (
format=format@entry=0x1a3f865 <gt_ggc_r_gt_ada_decl_h+517> "%s:%d",
args=args@entry=0x1367df64 "")
at ../../gcc-11.3.0/libiberty/xvasprintf.c:57
#3 0x017312f7 in xasprintf (
fmt=0x1a3f865 <gt_ggc_r_gt_ada_decl_h+517> "%s:%d")
at ../../gcc-11.3.0/libiberty/xasprintf.c:47
#4 0x0041f315 in internal_error_function (
context=0x29d40c0 <global_diagnostic_context>,
msgid=0x1b2aebd <gt_ggc_r_gt_targhooks_h+5853> "%s", ap=0x1367e0a0)
at ../../gcc-11.3.0/gcc/ada/gcc-interface/misc.c:343
#5 0x016ab28d in diagnostic_report_diagnostic (
context=0x29d40c0 <global_diagnostic_context>,
diagnostic=<optimized out>, diagnostic@entry=0x1367e048)
at ../../gcc-11.3.0/gcc/diagnostic.c:1225
#6 0x016ab7b7 in diagnostic_impl (richloc=0x1367e0a4, metadata=0x0, opt=-1,
gmsgid=0x1b2aebd <gt_ggc_r_gt_targhooks_h+5853> "%s", ap=0x1367e0a0,
kind=DK_ICE) at ../../gcc-11.3.0/gcc/diagnostic.c:1406
#7 0x016abd98 in internal_error (
gmsgid=gmsgid@entry=0x1b2aebd <gt_ggc_r_gt_targhooks_h+5853> "%s")
at ../../gcc-11.3.0/gcc/diagnostic.c:1808
#8 0x00c53db1 in crash_signal (signo=22) at ../../gcc-11.3.0/gcc/toplev.c:327
#9 0x75608081 in raise () from C:\WINDOWS\SysWOW64\msvcrt.dll
#10 0x00000016 in ?? ()
#11 0x4925a812 in ?? ()
#12 0x1367e7b0 in ?? ()
#13 0x7560c5ab in msvcrt!abort () from C:\WINDOWS\SysWOW64\msvcrt.dll
#14 0x0192e3d3 in uw_init_context_1 (context=0x0, context@entry=0x1367e730,
outer_cfa=outer_cfa@entry=0x1367e7d0, outer_ra=0x16)
at ../../../gcc-11.3.0/libgcc/unwind-dw2.c:1593
#15 0x0192e77f in _Unwind_RaiseException (exc=0x1619f880)
at ../../../gcc-11.3.0/libgcc/unwind.inc:93
#16 0x00473f47 in ada.exceptions.exception_propagation.propagate_gcc_exception
(gcc_exception=0x1619f880)
at ../../gcc-11.3.0/gcc/ada/libgnat/a-exexpr.adb:597
#17 0x00473f96 in ada.exceptions.exception_propagation.propagate_exception (
excep=...) at ../../gcc-11.3.0/gcc/ada/libgnat/a-exexpr.adb:628
#18 0x00474414 in ada.exceptions.complete_and_propagate_occurrence (
x=x@entry=0x1619f8b0) at ../../gcc-11.3.0/gcc/ada/libgnat/a-except.adb:924
#19 0x00474447 in <__gnat_raise_exception> (
e=e@entry=0x1a31698 <sem_ch13.build_discrete_static_predicate.non_static>,
message=...) at ../../gcc-11.3.0/gcc/ada/libgnat/a-except.adb:960
#20 0x0068e352 in sem_ch13.build_discrete_static_predicate.stat_pred (
typ=32975) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9368
#21 0x0068fa75 in sem_ch13.build_discrete_static_predicate.get_rlist (
exp=<optimized out>) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9129
#22 0x0068f922 in sem_ch13.build_discrete_static_predicate.get_rlist (
exp=203158) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9015
#23 0x00693b59 in sem_ch13.build_discrete_static_predicate (typ=33050,
expr=203158, nam=-399989278) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9409
#24 0x00696f66 in sem_ch13.build_predicate_functions (typ=typ@entry=33050,
n=n@entry=203112) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:10370
#25 0x006a59b2 in sem_ch13.freeze_entity_checks (n=203112)
at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:12728
#26 0x006a5ab5 in sem_ch13.analyze_freeze_entity (n=n@entry=203112)
at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:8155
#27 0x0064416a in sem.analyze (n=n@entry=203112)
at ../../gcc-11.3.0/gcc/ada/sem.adb:264
#28 0x00644d68 in sem.insert_list_after_and_analyze (n=203068, l=-99976824)
at ../../gcc-11.3.0/gcc/ada/sem.adb:1254
#29 0x005b490f in freeze.freeze_all.freeze_all_ent.process_flist ()
at ../../gcc-11.3.0/gcc/ada/freeze.adb:1852
#30 0x005bf0f5 in freeze.freeze_all.freeze_all_ent (after=36978, from=32525)
at ../../gcc-11.3.0/gcc/ada/freeze.adb:1940
#31 freeze.freeze_all (from=32525, after=36978)
at ../../gcc-11.3.0/gcc/ada/freeze.adb:2020
#32 0x006ad855 in sem_ch3.analyze_declarations (l=<optimized out>,
l@entry=-99996744) at ../../gcc-11.3.0/gcc/ada/sem_ch3.adb:2837
#33 0x006fa1d7 in sem_ch7.analyze_package_specification (n=n@entry=32524)
at ../../gcc-11.3.0/gcc/ada/sem_ch7.adb:1738
#34 0x006442f7 in sem.analyze (n=32524)
at ../../gcc-11.3.0/gcc/ada/sem.adb:459
#35 0x006f978c in sem_ch7.analyze_package_declaration (n=n@entry=37004)
at ../../gcc-11.3.0/gcc/ada/sem_ch7.adb:1210
#36 0x00643e5e in sem.analyze (n=n@entry=37004)
at ../../gcc-11.3.0/gcc/ada/sem.adb:450
#37 0x0066c17a in sem_ch10.analyze_compilation_unit (n=32501)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:913
#38 0x00644102 in sem.analyze (n=n@entry=32501)
at ../../gcc-11.3.0/gcc/ada/sem.adb:180
#39 0x006454b1 in sem.semantics.do_analyze ()
at ../../gcc-11.3.0/gcc/ada/sem.adb:1421
#40 sem.semantics (comp_unit=32501) at ../../gcc-11.3.0/gcc/ada/sem.adb:1615
#41 0x00668e97 in sem_ch10.analyze_with_clause (n=n@entry=95876)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:2634
#42 0x00644258 in sem.analyze (n=n@entry=95876)
at ../../gcc-11.3.0/gcc/ada/sem.adb:613
#43 0x006679a7 in sem_ch10.analyze_context (n=n@entry=95866)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:1433
#44 0x0066c0d9 in sem_ch10.analyze_compilation_unit (n=95866)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:700
#45 0x00644102 in sem.analyze (n=n@entry=95866)
at ../../gcc-11.3.0/gcc/ada/sem.adb:180
#46 0x006454b1 in sem.semantics.do_analyze ()
at ../../gcc-11.3.0/gcc/ada/sem.adb:1421
#47 sem.semantics (comp_unit=95866) at ../../gcc-11.3.0/gcc/ada/sem.adb:1615
#48 0x0066c138 in sem_ch10.analyze_compilation_unit (n=95901)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:878
#49 0x00644102 in sem.analyze (n=n@entry=95901)
at ../../gcc-11.3.0/gcc/ada/sem.adb:180
#50 0x006454b1 in sem.semantics.do_analyze ()
at ../../gcc-11.3.0/gcc/ada/sem.adb:1421
#51 sem.semantics (comp_unit=95901) at ../../gcc-11.3.0/gcc/ada/sem.adb:1615
#52 0x00668e97 in sem_ch10.analyze_with_clause (n=n@entry=38956)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:2634
#53 0x00644258 in sem.analyze (n=n@entry=38956)
at ../../gcc-11.3.0/gcc/ada/sem.adb:613
#54 0x006679a7 in sem_ch10.analyze_context (n=n@entry=38954)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:1433
#55 0x0066c0d9 in sem_ch10.analyze_compilation_unit (n=38954)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:700
#56 0x00644102 in sem.analyze (n=n@entry=38954)
at ../../gcc-11.3.0/gcc/ada/sem.adb:180
#57 0x006454b1 in sem.semantics.do_analyze ()
at ../../gcc-11.3.0/gcc/ada/sem.adb:1421
#58 sem.semantics (comp_unit=38954) at ../../gcc-11.3.0/gcc/ada/sem.adb:1615
#59 0x00668e97 in sem_ch10.analyze_with_clause (n=n@entry=13454)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:2634
#60 0x00644258 in sem.analyze (n=n@entry=13454)
at ../../gcc-11.3.0/gcc/ada/sem.adb:613
#61 0x006679a7 in sem_ch10.analyze_context (n=n@entry=13452)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:1433
#62 0x0066c0d9 in sem_ch10.analyze_compilation_unit (n=13452)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:700
#63 0x00644102 in sem.analyze (n=n@entry=13452)
at ../../gcc-11.3.0/gcc/ada/sem.adb:180
#64 0x006454b1 in sem.semantics.do_analyze ()
at ../../gcc-11.3.0/gcc/ada/sem.adb:1421
#65 sem.semantics (comp_unit=13452) at ../../gcc-11.3.0/gcc/ada/sem.adb:1615
#66 0x00668e97 in sem_ch10.analyze_with_clause (n=n@entry=2328)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:2634
#67 0x00644258 in sem.analyze (n=n@entry=2328)
at ../../gcc-11.3.0/gcc/ada/sem.adb:613
#68 0x006679a7 in sem_ch10.analyze_context (n=n@entry=2326)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:1433
#69 0x0066c0d9 in sem_ch10.analyze_compilation_unit (n=2326)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:700
#70 0x00644102 in sem.analyze (n=n@entry=2326)
at ../../gcc-11.3.0/gcc/ada/sem.adb:180
#71 0x006454b1 in sem.semantics.do_analyze ()
at ../../gcc-11.3.0/gcc/ada/sem.adb:1421
#72 sem.semantics (comp_unit=2326) at ../../gcc-11.3.0/gcc/ada/sem.adb:1615
#73 0x005c3a46 in frontend () at ../../gcc-11.3.0/gcc/ada/frontend.adb:422
#74 0x007f0e2d in gnat1drv () at ../../gcc-11.3.0/gcc/ada/gnat1drv.adb:1237
#75 0x0041f065 in gnat_parse_file ()
at ../../gcc-11.3.0/gcc/ada/gcc-interface/misc.c:118
#76 0x00c53ea3 in compile_file () at ../../gcc-11.3.0/gcc/toplev.c:457
#77 0x019efeba in do_compile () at ../../gcc-11.3.0/gcc/toplev.c:2201
#78 toplev::main (this=this@entry=0x1367feae, argc=<optimized out>,
argc@entry=32, argv=<optimized out>) at ../../gcc-11.3.0/gcc/toplev.c:2340
#79 0x01a1e1a6 in main (argc=32, argv=0x138a1a48)
at ../../gcc-11.3.0/gcc/main.c:39
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
2022-05-17 18:28 ` [Bug ada/105507] " reiter.christoph at gmail dot com
2022-05-18 19:47 ` reiter.christoph at gmail dot com
@ 2022-05-18 20:09 ` ebotcazou at gcc dot gnu.org
2022-05-18 21:02 ` reiter.christoph at gmail dot com
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2022-05-18 20:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |100486
Last reconfirmed| |2022-05-18
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
It's an issue in the base compiler though, not in GCC 12.x, probably the same
as the one reported under PR ada/100486: exception propagation in the compiler
does not work in your setup for some reason.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486
[Bug 100486] Ada build fails for 32bit Windows
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
` (2 preceding siblings ...)
2022-05-18 20:09 ` ebotcazou at gcc dot gnu.org
@ 2022-05-18 21:02 ` reiter.christoph at gmail dot com
2022-05-18 22:05 ` ebotcazou at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: reiter.christoph at gmail dot com @ 2022-05-18 21:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #4 from Christoph Reiter <reiter.christoph at gmail dot com> ---
I see, thanks for having a look :)
We do have some open bugs re broken exception handling with mingw32, like
https://github.com/msys2/MINGW-packages/issues/9289#issuecomment-945306860
Sadly no one stepped up to look into that. Do you think this could be related?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
` (3 preceding siblings ...)
2022-05-18 21:02 ` reiter.christoph at gmail dot com
@ 2022-05-18 22:05 ` ebotcazou at gcc dot gnu.org
2022-05-18 22:26 ` ebotcazou at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2022-05-18 22:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> We do have some open bugs re broken exception handling with mingw32, like
> https://github.com/msys2/MINGW-packages/issues/9289#issuecomment-945306860
>
> Sadly no one stepped up to look into that. Do you think this could be
> related?
Possible, but the above report clearly points to pitfall #1 with DWARF
unwinding: you may *not* have more than a single libgcc in a link. This means
that, if you link with a DLL that was linked with the (shared, that's
requuired) libgcc, you *cannot* also link with the static libgcc, because this
brings 2 libgccs in the link, you *must* link with the shared libgcc.
So the rule of thumb is to never use -static-libgcc if you have a GCC-compiled
DLL in the link, that's guaranteed to break otherwise.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
` (4 preceding siblings ...)
2022-05-18 22:05 ` ebotcazou at gcc dot gnu.org
@ 2022-05-18 22:26 ` ebotcazou at gcc dot gnu.org
2022-05-19 6:40 ` reiter.christoph at gmail dot com
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2022-05-18 22:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> So the rule of thumb is to never use -static-libgcc if you have a
> GCC-compiled DLL in the link, that's guaranteed to break otherwise.
So this could happen to the compiler if it is linked with the shared version of
GMP, MPFR or MPC. Is that the case in your setup?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
` (5 preceding siblings ...)
2022-05-18 22:26 ` ebotcazou at gcc dot gnu.org
@ 2022-05-19 6:40 ` reiter.christoph at gmail dot com
2022-05-19 9:46 ` ebotcazou at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: reiter.christoph at gmail dot com @ 2022-05-19 6:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #7 from Christoph Reiter <reiter.christoph at gmail dot com> ---
We currently link:
shared: gmp, winpthread, zlib, zstd
static: mpc, mpfr, isl
Not for any particular gcc related reason I think, some dependent packages have
static/shared builds, some don't.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
` (6 preceding siblings ...)
2022-05-19 6:40 ` reiter.christoph at gmail dot com
@ 2022-05-19 9:46 ` ebotcazou at gcc dot gnu.org
2022-05-19 16:14 ` reiter.christoph at gmail dot com
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2022-05-19 9:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> We currently link:
>
> shared: gmp, winpthread, zlib, zstd
> static: mpc, mpfr, isl
>
> Not for any particular gcc related reason I think, some dependent packages
> have static/shared builds, some don't.
Why didn't I think of that for PR ada/100486? So the fix should have been to
add -shared-libgcc to GCC_LINKERFLAGS in gcc/ada/gcc-interface/Make-lang.in:
# Strip -Werror during linking for the LTO bootstrap
GCC_LINKERFLAGS = $(filter-out -Werror, $(ALL_LINKERFLAGS)) -shared-libgcc
in your setup since you link gnat1 with shared libraries. This should override
the -static-libgcc in ALL_LINKERFLAGS inherited from toplevel.
So you need to to it 1) for GCC 11: rebuild it and reinstall it 2) for GCC 12:
build it with the patched GCC 11. Note that this means that GCC 11 is
currently not fully functional anyway.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
` (7 preceding siblings ...)
2022-05-19 9:46 ` ebotcazou at gcc dot gnu.org
@ 2022-05-19 16:14 ` reiter.christoph at gmail dot com
2022-05-19 16:55 ` ebotcazou at gcc dot gnu.org
2022-05-22 15:14 ` reiter.christoph at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: reiter.christoph at gmail dot com @ 2022-05-19 16:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #9 from Christoph Reiter <reiter.christoph at gmail dot com> ---
(In reply to Eric Botcazou from comment #8)
> > We currently link:
> >
> > shared: gmp, winpthread, zlib, zstd
> > static: mpc, mpfr, isl
> >
> > Not for any particular gcc related reason I think, some dependent packages
> > have static/shared builds, some don't.
>
> Why didn't I think of that for PR ada/100486?
Sorry, I didn't know this was a problem :) I'm not quite sure how I ended up
maintaining this downstream... but here we are.
> So the fix should have been
> to add -shared-libgcc to GCC_LINKERFLAGS in
> gcc/ada/gcc-interface/Make-lang.in:
>
> # Strip -Werror during linking for the LTO bootstrap
> GCC_LINKERFLAGS = $(filter-out -Werror, $(ALL_LINKERFLAGS)) -shared-libgcc
>
> in your setup since you link gnat1 with shared libraries. This should
> override the -static-libgcc in ALL_LINKERFLAGS inherited from toplevel.
>
> So you need to to it 1) for GCC 11: rebuild it and reinstall it 2) for GCC
> 12: build it with the patched GCC 11. Note that this means that GCC 11 is
> currently not fully functional anyway.
Thanks for the detailed instructions. I'll give that a try.
I'm wondering if there are any downsides to just removing "-static-libgcc" from
both "--with-stage1-ldflags" and "--with-boot-ldflags". Or is only ada using
exceptions in GCC?
Or should we try linking everything statically to avoid this alltogether?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
` (8 preceding siblings ...)
2022-05-19 16:14 ` reiter.christoph at gmail dot com
@ 2022-05-19 16:55 ` ebotcazou at gcc dot gnu.org
2022-05-22 15:14 ` reiter.christoph at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2022-05-19 16:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I'm wondering if there are any downsides to just removing "-static-libgcc"
> from both "--with-stage1-ldflags" and "--with-boot-ldflags".
None presumably, since you already have dependencies on DLLs.
> Or is only ada using exceptions in GCC?
Yes, they are prohibited in the C++ codebase for the time being.
> Or should we try linking everything statically to avoid this alltogether?
It's your call, either should work equally well.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug ada/105507] Ada build fails for 32bit Windows
2022-05-06 15:23 [Bug ada/105507] New: Ada build fails for 32bit Windows reiter.christoph at gmail dot com
` (9 preceding siblings ...)
2022-05-19 16:55 ` ebotcazou at gcc dot gnu.org
@ 2022-05-22 15:14 ` reiter.christoph at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: reiter.christoph at gmail dot com @ 2022-05-22 15:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
Christoph Reiter <reiter.christoph at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #11 from Christoph Reiter <reiter.christoph at gmail dot com> ---
I went with --with-boot-ldflags="-static-libstdc++" and
--with-stage1-ldflags="-static-libstdc++" now, and everything works nicely.
Thanks for your help and insight.
I'll document the dwarf-2 limitation downstream, so this hopefully wont happen
again.
^ permalink raw reply [flat|nested] 12+ messages in thread