[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #14 from Arsen Arsenović --- indeed, system gettext should be unaffected.
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-03-27 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |arsen at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #13 from Richard Biener --- Looks like the patch is still not reviewed. I haven't had issues with using system gettext though.
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #12 from Arsen Arsenović --- (In reply to seurer from comment #11) > Did it work? yes, I sent it on the ML: https://inbox.sourceware.org/gcc-patches/20231221193243.368541-1-ar...@aarsen.me/
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #11 from seurer at gcc dot gnu.org --- Did it work?
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #10 from Arsen Arsenović --- Created attachment 56915 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56915=edit [PATCH] toplevel: don't override gettext-runtime/configure-discovered build args here's a preliminary patch, currently trying it on cfarm112.
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #9 from Arsen Arsenović --- removing EXTRA_HOST_FLAGS from the gettext targets fixed the build on my cfarm112. overall, I'm not sure overriding what subconfigures discover and adjust CC and CFLAGS with is a good idea. it seems sensible to allow subpackages to have that disabled (or to require packages to enable that functionality, but that change would be more intrusive)
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #8 from Arsen Arsenović --- (In reply to Jakub Jelinek from comment #7) > Exporting say CC or CXX to the host CC/CXX in stage1 and previous-stage/xgcc > -B previous-stage/ and similar is obviously required, otherwise bootstrap > wouldn't work at all. And various config/*.mk amend various other make > variables in various different stages as needed. sure, but is that necessary in 'all-*' stages if 'configure-*' already had CC et al exported?
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #7 from Jakub Jelinek --- (In reply to Arsen Arsenović from comment #6) > yes, that seems doable but I am curious about why the flag propagation via > export is necessary. would each configure not already have the appropriate > flags set? Exporting say CC or CXX to the host CC/CXX in stage1 and previous-stage/xgcc -B previous-stage/ and similar is obviously required, otherwise bootstrap wouldn't work at all. And various config/*.mk amend various other make variables in various different stages as needed.
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #6 from Arsen Arsenović --- (In reply to Jakub Jelinek from comment #5) > The problem is that the toplevel configure (which is autoconf 2.69 as pretty > much everything in gcc) uses the older AC_PROG_CC, which only checks for > -std=gnu99 -std=c99 -c99 -AC99 -D_STDC_C99= -qlanglvl=extc99, not for > -std=gnu11. > And sets > CC = @CC@ > in toplevel Makefile.in to > CC = gcc -std=gnu99 > in toplevel objdir Makefile. That gets then passed to in-tree gettext (if > present, I really don't think you need it on powerpc64-linux-gnu, perhaps > download_prerequisities should be smarter and check if gettext is really > needed) configure (where it just means > CC is set there to gcc -std=gnu99 -std=gnu11 in gettext/Makefile), but worse > is passed as CC="gcc -std=gnu99" in environment down when doing make all in > the gettext subdir. > I think that is something very similar to how CXX="g++ -std=c++11" is being > passed down > to in-tree isl build and breaks with recent isl which wants to use C++17 or > what. > Strangely, in my x86_64-linux toplevel Makefile I only have > CC = gcc > CXX = g++ -std=c++11 > Dunno why it hasn't added -std=gnu99 there, maybe because that gcc already > defaults to gnu17? Anyway, even when CC = gcc, I think that is passed down > to make of the in-tree compilations. > So, I guess if we don't want to switch to autoconf 2.70 or later (which I > think is a lot of work), one possibility if we know gettext relies on C11 > and newest ISL relies on C++17 (does it really?) would be to add explicit > probing in configure for -std=gnu11 or -std=c11 and if that works, pass it > down in the gettext build case; and similarly for isl. Maybe better not in > CC/CXX but in CFLAGS/CXXFLAGS? > The propagation of flags is done in $(HOST_EXPORTS) and for stage2+ > $(POSTSTAGE1_HOST_EXPORTS). > > Looking around in Makefile.def, I see e.g. for gmp/mpfr we use > extra_make_flags='AM_CFLAGS="-DNO_ASM"'; > and for isl > extra_make_flags='V=1'; > Dunno if it would work to add for the gettext case > extra_make_flags='CFLAGS="$(CFLAGS) @C11_CFLAGS@"'; > with configure check for C11_FLAGS or something similar. yes, that seems doable but I am curious about why the flag propagation via export is necessary. would each configure not already have the appropriate flags set?
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- The problem is that the toplevel configure (which is autoconf 2.69 as pretty much everything in gcc) uses the older AC_PROG_CC, which only checks for -std=gnu99 -std=c99 -c99 -AC99 -D_STDC_C99= -qlanglvl=extc99, not for -std=gnu11. And sets CC = @CC@ in toplevel Makefile.in to CC = gcc -std=gnu99 in toplevel objdir Makefile. That gets then passed to in-tree gettext (if present, I really don't think you need it on powerpc64-linux-gnu, perhaps download_prerequisities should be smarter and check if gettext is really needed) configure (where it just means CC is set there to gcc -std=gnu99 -std=gnu11 in gettext/Makefile), but worse is passed as CC="gcc -std=gnu99" in environment down when doing make all in the gettext subdir. I think that is something very similar to how CXX="g++ -std=c++11" is being passed down to in-tree isl build and breaks with recent isl which wants to use C++17 or what. Strangely, in my x86_64-linux toplevel Makefile I only have CC = gcc CXX = g++ -std=c++11 Dunno why it hasn't added -std=gnu99 there, maybe because that gcc already defaults to gnu17? Anyway, even when CC = gcc, I think that is passed down to make of the in-tree compilations. So, I guess if we don't want to switch to autoconf 2.70 or later (which I think is a lot of work), one possibility if we know gettext relies on C11 and newest ISL relies on C++17 (does it really?) would be to add explicit probing in configure for -std=gnu11 or -std=c11 and if that works, pass it down in the gettext build case; and similarly for isl. Maybe better not in CC/CXX but in CFLAGS/CXXFLAGS? The propagation of flags is done in $(HOST_EXPORTS) and for stage2+ $(POSTSTAGE1_HOST_EXPORTS). Looking around in Makefile.def, I see e.g. for gmp/mpfr we use extra_make_flags='AM_CFLAGS="-DNO_ASM"'; and for isl extra_make_flags='V=1'; Dunno if it would work to add for the gettext case extra_make_flags='CFLAGS="$(CFLAGS) @C11_CFLAGS@"'; with configure check for C11_FLAGS or something similar.
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #4 from Arsen Arsenović --- (In reply to Bruno Haible from comment #2) > > gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) > > gcc -std=gnu99 ... > > error: unknown type name 'max_align_t' > > The type 'max_align_t' exists in C11, but not in C99, as can be seen from > these uses of gcc 4.8.5: > $ cat foo.c > #include > max_align_t x; > $ gcc -std=c11 -c foo.c > $ gcc -std=gnu11 -c foo.c > $ gcc -std=c99 -c foo.c > foo.c:2:1: error: unknown type name ‘max_align_t’ > max_align_t x; > ^ > $ gcc -std=gnu99 -c foo.c > foo.c:2:1: error: unknown type name ‘max_align_t’ > max_align_t x; > ^ > > But this occurs in the build tree of gettext-runtime, and this package uses > AC_PROG_CC, which adds option -std=gnu11 if supported (this is in GNU > Autoconf since version 2.70). > > Maybe some configure file was built with Autoconf 2.69 and older and thus > does not add -std=gnu11 ? The toolchain tree is generated with AC2.69, indeed. The gettext-runtime files should be unaltered from the release gettext tarball, though. > Or some other configure in the build tree has determined CC="gcc > -std=gnu99", and this setting has been propagated into gettext-runtime, > overriding the findings from gettext-runtime/configure ?
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||build
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #3 from Bruno Haible --- (In reply to Andrew Pinski from comment #1) > Hmm. similar issue happen with gdb 5 years ago: > https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00151.html Thanks; this is helpful. In this thread we have the explanation https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00158.html, which could maybe be the root cause of the problem here. > Looks like this is huge gnulib mess at that. This comment is not helpful. 1) As shown in the previous comment, max_align_t problems arise from the use of -std=... options that are too old. We are in the year 2023, and it seems right to use ISO C 11 features (from a 12 years old standard), no? 2) Gnulib actually works around two problems related to max_align_t, as documented here: https://www.gnu.org/software/gnulib/manual/html_node/stddef_002eh.html Without Gnulib, you would encounter more problems related to max_align_t, not fewer.
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #2 from Bruno Haible --- > gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) > gcc -std=gnu99 ... > error: unknown type name 'max_align_t' The type 'max_align_t' exists in C11, but not in C99, as can be seen from these uses of gcc 4.8.5: $ cat foo.c #include max_align_t x; $ gcc -std=c11 -c foo.c $ gcc -std=gnu11 -c foo.c $ gcc -std=c99 -c foo.c foo.c:2:1: error: unknown type name ‘max_align_t’ max_align_t x; ^ $ gcc -std=gnu99 -c foo.c foo.c:2:1: error: unknown type name ‘max_align_t’ max_align_t x; ^ But this occurs in the build tree of gettext-runtime, and this package uses AC_PROG_CC, which adds option -std=gnu11 if supported (this is in GNU Autoconf since version 2.70). Maybe some configure file was built with Autoconf 2.69 and older and thus does not add -std=gnu11 ? Or some other configure in the build tree has determined CC="gcc -std=gnu99", and this setting has been propagated into gettext-runtime, overriding the findings from gettext-runtime/configure ?
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #1 from Andrew Pinski --- Hmm. similar issue happen with gdb 5 years ago: https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00151.html Looks like this is huge gnulib mess at that.