Bug 211742
| Summary: | lang/gcc{46, 47, 48, 49, 5*, 6*}: Fails to build on 11.0-CURRENT (and 11.0-BETA4) with non-C locale | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | iron.udjin | ||||
| Component: | Individual Port(s) | Assignee: | Gerald Pfeifer <gerald> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | feld, graham, koobs, marino, ports-secteam | ||||
| Priority: | --- | Keywords: | patch | ||||
| Version: | Latest | Flags: | koobs:
maintainer-feedback+
koobs: merge-quarterly- |
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216124 | ||||||
| Bug Depends on: | 210122 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Created attachment 173537 [details]
Proposed patch.
Can you please give the attached patch a try?
(In reply to Gerald Pfeifer from comment #1) The patch has solved compilation problem. Thank you! A commit references this bug: Author: gerald Date: Thu Aug 11 09:40:58 UTC 2016 New revision: 420055 URL: https://svnweb.freebsd.org/changeset/ports/420055 Log: GCC uses an AWK script to generate source code that helps process command-line options. According to POSIX, string comparisons (and hence sorting) are to be performed based on the locale's collating order. Alas GNU AWK only does so in POSIX mode, whereas starting with FreeBSD 11 we do so by default, running into a bug (or false assumption) with that script used by GCC. Setting MAKE_ARGS such that AWK is always invoked in the C locale works around this bug. PR: 211742 Submitted by: jkim Changes: head/lang/gcc49/Makefile Thanks for the report, and of course thanks to jkim@ for an earlier analysis and proposed fix. I am closing this PR, but will push the same fix to other lang/gcc* ports. *** Bug 210122 has been marked as a duplicate of this bug. *** Re-open pending resolution (commit/merge) of other gcc ports A commit references this bug: Author: gerald Date: Sat Aug 13 20:44:21 UTC 2016 New revision: 420165 URL: https://svnweb.freebsd.org/changeset/ports/420165 Log: Update to the 20160811 snapshot of GCC 6. GCC uses an AWK script to generate source code that helps process command-line options. According to POSIX, string comparisons (and hence sorting) are to be performed based on the locale's collating order. Alas GNU AWK only does so in POSIX mode, whereas starting with FreeBSD 11 we do so by default, running into a bug (or false assumption) with that script used by GCC. Setting MAKE_ARGS such that AWK is always invoked in the C locale works around this bug. [1] PR: 210122 [1], 211742 [1] Submitted by: jkim [1] Changes: head/lang/gcc6-devel/Makefile head/lang/gcc6-devel/distinfo A commit references this bug: Author: gerald Date: Sun Aug 14 07:28:14 UTC 2016 New revision: 420178 URL: https://svnweb.freebsd.org/changeset/ports/420178 Log: GCC uses an AWK script to generate source code that helps process command-line options. According to POSIX, string comparisons (and hence sorting) are to be performed based on the locale's collating order. Alas GNU AWK only does so in POSIX mode, whereas starting with FreeBSD 11 we do so by default, running into a bug (or false assumption) with that script used by GCC. Setting MAKE_ARGS such that AWK is always invoked in the C locale works around this bug. PR: 210122, 211742 Submitted by: jkim Changes: head/lang/gcc/Makefile head/lang/gcc/distinfo Update summary to explicitly include GCC ports that are affected (having tested them) so it's clear which have been fixed (in commit comments) and which are pending. Fixed so far: lang/gcc49 (comment 3) lang/gcc6-devel (comment 7) lang/gcc (comment 8) via bug 210122 Pending fixes (at this time): lang/gcc46 lang/gcc47 lang/gcc48 lang/gcc5 lang/gcc5-devel lang/gcc6 I'm unsure whether the gcc{5,6}-aux ports are also affected. All should be MFH'd to the quarterly branch (none fixed so far have been), otherwise quarterly users will remain affected. Link "same issue different port" bug 210122 so people can find it (technical duplicate but tracked separately) (In reply to Kubilay Kocak from comment #9) > Pending fixes (at this time): > lang/gcc46 > lang/gcc47 > lang/gcc48 > lang/gcc5 > lang/gcc5-devel > lang/gcc6 I am not planning to adjust lang/gcc46, lang/gcc47, and lang/gcc48. I will update lang/gcc5-devel with the next upstream snapshot in two days, and lang/gcc5 and lang/gcc6 with the next release (pending in one case). Unless I get earlier reports from users that is. > I'm unsure whether the gcc{5,6}-aux ports are also affected. From all I can tell, the should, and I have given John Marino (their maintainer) a heads-up. (In reply to Gerald Pfeifer from comment #11) Why no fixes to lang/gcc46, lang/gcc47, and lang/gcc48 and why no MFH's for any? My comment 9 was reporting the issue on those versions (In reply to Kubilay Kocak from comment #12) > Why no fixes to lang/gcc46, lang/gcc47, and lang/gcc48 Those are end-of-life and really should not be used any more. In the past I would have removed them already, but at least one committer asked for old versions to be retained last time. > and why no MFH's for any? I had already set "gerald: merge-quarterly" to "+" and am happy if someone wants to push that back. (In reply to Gerald Pfeifer from comment #13) I understand, however: - lang/gcc has been fixed, but lang/gcc48 (same version) has not - GCC_DEFAULT is gcc48 - lang/gcc46 has 10 build/run dependents - lang/gcc47 has a dependent cad/kicad - none of gcc46 gcc47 gcc48 have pkg-messages / DEPRECATED / EXPIRES / EXPIRATION_DATE These ports are very important toolchain components with undoubtedly many consumers downstream. They should be fixed completely and consistently, especially given the miniscule size of the change. If you're limited on time, I'd be more than happy to help complete resolution on this issue (and merge them to the quarterly branch). This is an example of treating the symptom, not the cause. Awk isn't the only one affected by this; sed has the same problem. The solution is to set LANG/COLLATE/whatever globally in the ports framework to POSIX. The user's locale should never leak into the build. I think we already did this for dports and it's time to do it for ports too. (In reply to John Marino from comment #15) In that case we should close this bug as Rejected(?) and open another that properly targets the fix in the ports tree framework and request an exp-run. (In reply to Mark Felder from comment #16) Rejected is incorrect as changes (commits) have already been made as a consequence of this issue report. If a framework change is the preferred resolution path, then the correct method is to leave this issue opened, (resolution) blocked on a new issue: "Mk/bsd.whatever.mk: Set LANG,COLLATE,BLAH to VALUE globally" If that happens, we would expect to see the changes made in revisions 420055 420165 420178 for this issue removed before closing here. If it were me, I'd finish this issue properly and create a new (non-blocking see also:) issue for the framework change separately. There is no reason to keep 70% of the ports GCC toolchain broken (in head and quarterly) until that framework change is reviewed, qa's and made. Further, that framework change would also need to be MFH'd, where the quarterly versions of all gcc ports are also affected by this bug (Another reason for the recommendation to finish this issue). This makes sense, thanks koobs I was trying to find where we did this for illustration purposes, and it appears that I misremembered. I changed poudriere (DF) and synth (all) to set LANG=C in the environment, but I didn't change the ports framework directly. Obviously I think the framework should take care of it for those that insist on building dirty. A commit references this bug: Author: gerald Date: Tue Aug 16 07:21:06 UTC 2016 New revision: 420267 URL: https://svnweb.freebsd.org/changeset/ports/420267 Log: GCC uses an AWK script to generate source code that helps process command-line options. According to POSIX, string comparisons (and hence sorting) are to be performed based on the locale's collating order. Alas GNU AWK only does so in POSIX mode, whereas starting with FreeBSD 11 we do so by default, running into a bug (or false assumption) with that script used by GCC. Setting MAKE_ARGS such that AWK is always invoked in the C locale works around this bug. PR: 210122, 211742 Submitted by: jkim Changes: head/lang/gcc48/Makefile head/lang/gcc48/distinfo A commit references this bug: Author: gerald Date: Wed Aug 17 09:02:54 UTC 2016 New revision: 420325 URL: https://svnweb.freebsd.org/changeset/ports/420325 Log: Update to the 20160816 snapshot of GCC 5.4.1. GCC uses an AWK script to generate source code that helps process command-line options. According to POSIX, string comparisons (and hence sorting) are to be performed based on the locale's collating order. Alas GNU AWK only does so in POSIX mode, whereas starting with FreeBSD 11 we do so by default, running into a bug (or false assumption) with that script used by GCC. Setting MAKE_ARGS such that AWK is always invoked in the C locale works around this bug. [1] PR: 210122 [1], 211742 [1] Submitted by: jkim [1] Changes: head/lang/gcc5-devel/Makefile head/lang/gcc5-devel/distinfo A commit references this bug: Author: gerald Date: Wed Aug 17 16:22:50 UTC 2016 New revision: 420359 URL: https://svnweb.freebsd.org/changeset/ports/420359 Log: Backport the following from lang/gcc5-devel: GCC uses an AWK script to generate source code that helps process command-line options. According to POSIX, string comparisons (and hence sorting) are to be performed based on the locale's collating order. Alas GNU AWK only does so in POSIX mode, whereas starting with FreeBSD 11 we do so by default, running into a bug (or false assumption) with that script used by GCC. Setting MAKE_ARGS such that AWK is always invoked in the C locale works around this bug. PR: 210122, 211742 Submitted by: jkim Changes: head/lang/gcc5/Makefile A commit references this bug: Author: gerald Date: Mon Aug 22 13:20:47 UTC 2016 New revision: 420613 URL: https://svnweb.freebsd.org/changeset/ports/420613 Log: Update to the GCC 6.2 release with a fair number of fixes. files/patch-armv6-hf-support has been accepted upstream, even on the GCC 6-branch this release comes from, so remove it. Backport the following from lang/gcc6-devel: GCC uses an AWK script to generate source code that helps process command-line options. According to POSIX, string comparisons (and hence sorting) are to be performed based on the locale's collating order. Alas GNU AWK only does so in POSIX mode, whereas starting with FreeBSD 11 we do so by default, running into a bug (or false assumption) with that script used by GCC. Setting MAKE_ARGS such that AWK is always invoked in the C locale works around this bug. [1] PR: 210122 [1], 211742 [1] Submitted by: jkim [1] Changes: head/lang/gcc6/Makefile head/lang/gcc6/distinfo head/lang/gcc6/files/patch-armv6-hf-support (In reply to Kubilay Kocak from comment #14) > I understand, however: > > - lang/gcc has been fixed, but lang/gcc48 (same version) has not I have now pushed this "fix" / workaround to lang/gcc48 as well. > - GCC_DEFAULT is gcc48 GCC_DEFAULT is 4.8, which implies lang/gcc, not lang/gcc48 (but accepts lang/gcc48 if installed). > - lang/gcc46 has 10 build/run dependents > - lang/gcc47 has a dependent cad/kicad There have been zero reports from users. And in all those cases these ports are in an awful state: they are not buildable with the system compiler (whichever that is), they are not buildable with clang, they are not buildable with a decently modern version of GCC (4.8 has been released 3.5 years ago). If anyone has excess energy, fixing (or removing) those embarrassing ports would be good. > If you're limited on time, I'd be more than happy to help complete > resolution on this issue (and merge them to the quarterly branch). Yes, I'd be happy to see you push the existing fixes for lang/gcc and lang/gcc48 and later to the quarterly branch. @Gerald probably not worth MFH'ing now that the next quarterly will be cut soon. It would have been better to commit the same fix to all gcc ports in one commit, and merging to quarterly on the same day. Do all gcc ports now carry the LANG!=C fix in head? If so, we can close this as resolved. While I'm here, set merge-quarterly to - since no head commits will be merged there. (In reply to Kubilay Kocak from comment #25) > Do all gcc ports now carry the LANG!=C fix in head? If so, we can > close this as resolved. Yes, all lang/gcc* ports except for lang/gcc7-devel now carry the workaround. I will submit a patch to avoid this to upstream GCC (for GCC 7), so gcc7-devel hopefully will be covered soon as well. And I just submitted PR 216124 to address this more generally as part of the FreeBSD Ports Collection overall, including a proposed patch. |
I'm use 11.0-BETA4 r303897M which built from -STABLE. When I try to build gcc49 I get error: c++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc -I/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/build -I/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/../include -I/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/../libcpp/include -DLIBICONV_PLUG \ -o build/genconstants.o /usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/genconstants.c c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated c++ -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genconstants \ build/genconstants.o build/read-md.o build/errors.o ../build-x86_64-portbld-freebsd11.0/libiberty/libiberty.a build/genconstants /usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/config/i386/i386.md \ > tmp-constants.h /bin/sh /usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/../move-if-change tmp-constants.h insn-constants.h echo timestamp > s-constants c++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc -I/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/build -I/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/../include -I/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/../libcpp/include -DLIBICONV_PLUG \ -o build/genpreds.o /usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/genpreds.c c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated In file included from /usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/genpreds.c:26: In file included from ./tm.h:16: ./options.h:4558:3: error: redefinition of enumerator 'OPT_C' OPT_C = 129, /* -C */ ^ ./options.h:4555:3: note: previous definition is here OPT_C = 126, /* -C */ ^ ./options.h:4566:3: error: redefinition of enumerator 'OPT_d' OPT_d = 137, /* -d */ ^ ./options.h:4564:3: note: previous definition is here OPT_d = 135, /* -d */ ^ ./options.h:4567:3: error: redefinition of enumerator 'OPT_D' OPT_D = 138, /* -D */ ^ ./options.h:4565:3: note: previous definition is here OPT_D = 136, /* -D */ ^ ./options.h:4570:3: error: redefinition of enumerator 'OPT_d' OPT_d = 141, /* -d */ ^ ./options.h:4564:3: note: previous definition is here OPT_d = 135, /* -d */ ^ ./options.h:4571:3: error: redefinition of enumerator 'OPT_D' OPT_D = 142, /* -D */ ^ ./options.h:4565:3: note: previous definition is here OPT_D = 136, /* -D */ ^ ./options.h:4572:3: error: redefinition of enumerator 'OPT_d' OPT_d = 143, /* -d */ ^ ./options.h:4564:3: note: previous definition is here OPT_d = 135, /* -d */ ^ ./options.h:4580:3: error: redefinition of enumerator 'OPT_E' OPT_E = 151, /* -E */ ^ ./options.h:4578:3: note: previous definition is here OPT_E = 149, /* -E */ ^ ./options.h:5200:3: error: redefinition of enumerator 'OPT_H' OPT_H = 771, /* -H */ ^ ./options.h:5198:3: note: previous definition is here OPT_H = 769, /* -H */ ^ ./options.h:5203:3: error: redefinition of enumerator 'OPT_I' OPT_I = 774, /* -I */ ^ ./options.h:5201:3: note: previous definition is here OPT_I = 772, /* -I */ ^ ./options.h:5267:3: error: redefinition of enumerator 'OPT_MF' OPT_MF = 838, /* -MF */ ^ ./options.h:5265:3: note: previous definition is here OPT_MF = 836, /* -MF */ ^ ./options.h:5271:3: error: redefinition of enumerator 'OPT_M' OPT_M = 842, /* -M */ ^ ./options.h:5253:3: note: previous definition is here OPT_M = 824, /* -M */ ^ ./options.h:5285:3: error: redefinition of enumerator 'OPT_M' OPT_M = 856, /* -M */ ^ ./options.h:5253:3: note: previous definition is here OPT_M = 824, /* -M */ ^ ./options.h:5297:3: error: redefinition of enumerator 'OPT_MM' OPT_MM = 868, /* -MM */ ^ ./options.h:5292:3: note: previous definition is here OPT_MM = 863, /* -MM */ ^ ./options.h:5313:3: error: redefinition of enumerator 'OPT_MP' OPT_MP = 884, /* -MP */ ^ ./options.h:5308:3: note: previous definition is here OPT_MP = 879, /* -MP */ ^ ./options.h:5373:3: error: redefinition of enumerator 'OPT_o' OPT_o = 944, /* -o */ ^ ./options.h:5370:3: note: previous definition is here OPT_o = 941, /* -o */ ^ ./options.h:5375:3: error: redefinition of enumerator 'OPT_o' OPT_o = 946, /* -o */ ^ ./options.h:5370:3: note: previous definition is here OPT_o = 941, /* -o */ ^ ./options.h:5382:3: error: redefinition of enumerator 'OPT_P' OPT_P = 953, /* -P */ ^ ./options.h:5378:3: note: previous definition is here OPT_P = 949, /* -P */ ^ ./options.h:5484:3: error: redefinition of enumerator 'OPT_U' OPT_U = 1055, /* -U */ ^ ./options.h:5482:3: note: previous definition is here OPT_U = 1053, /* -U */ ^ ./options.h:5488:3: error: redefinition of enumerator 'OPT_v' OPT_v = 1059, /* -v */ ^ ./options.h:5486:3: note: previous definition is here OPT_v = 1057, /* -v */ ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. gmake[5]: *** [Makefile:2366: build/genpreds.o] Error 1 gmake[5]: Leaving directory '/usr/ports/lang/gcc49/work/.build/gcc' gmake[4]: *** [Makefile:4219: all-stage1-gcc] Error 2 gmake[4]: Leaving directory '/usr/ports/lang/gcc49/work/.build' gmake[3]: *** [Makefile:18870: stage1-bubble] Error 2 gmake[3]: Leaving directory '/usr/ports/lang/gcc49/work/.build' gmake[2]: *** [Makefile:19202: bootstrap-lean] Error 2 gmake[2]: Leaving directory '/usr/ports/lang/gcc49/work/.build' *** Error code 1