[Bug ada/105507] New: Ada build fails for 32bit Windows

[Bug ada/105507] New: Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507

            Bug ID: 105507
           Summary: Ada build fails for 32bit Windows
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: reiter.christoph at gmail dot com
  Target Milestone: ---

Downstream context: https://github.com/msys2/MINGW-packages/pull/11582

Building gcc 12.1.0 fails for 32bit Windows (64bit works):

$ make
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[2]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
rm -f stage_current
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[2]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[2]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty'
make[4]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty/testsuite'
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin'
make  all-am
make[4]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin'
make[4]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin'
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/intl'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/intl'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty'
make[4]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty/testsuite'
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/fixincludes'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/fixincludes'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libcpp'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace'
make  all-am
make[4]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace'
true  DO=all multi-do # make
make[4]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace'
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcpp'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcody'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcody'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libdecnumber'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libdecnumber'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc'
mkdir -p ada/
gcc -c -g  -gnatpg -gnatwns  -W -Wall -I- -I. -Iada/generated -Iada
-I../../gcc-12.1.0/gcc/ada ../../gcc-12.1.0/gcc/ada/spark_xrefs.adb -o
ada/spark_xrefs.o
gcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/msys2/MINGW-packages/issues> for instructions.
make[3]: *** [../../gcc-12.1.0/gcc/ada/gcc-interface/Make-lang.in:167:
ada/spark_xrefs.o] Error 4
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc'
make[2]: *** [Makefile:4974: all-stage1-gcc] Error 2
make[2]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[1]: *** [Makefile:25946: stage1-bubble] Error 2
make[1]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make: *** [Makefile:1084: all] Error 2

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com]

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(-)

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com]

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

[Bug ada/105507] Ada build fails for 32bit Windows

[ebotcazou at gcc dot gnu.org]

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

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com]

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?

[Bug ada/105507] Ada build fails for 32bit Windows

[ebotcazou at gcc dot gnu.org]

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.

[Bug ada/105507] Ada build fails for 32bit Windows

[ebotcazou at gcc dot gnu.org]

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?

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com]

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.

[Bug ada/105507] Ada build fails for 32bit Windows

[ebotcazou at gcc dot gnu.org]

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.

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com]

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?

[Bug ada/105507] Ada build fails for 32bit Windows

[ebotcazou at gcc dot gnu.org]

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.

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com]

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.