Comment 1 Gerald Pfeifer 2016-08-11 07:05:05 UTC

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!

Comment 3 commit-hook 2016-08-11 09:41:43 UTC

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

Comment 4 Gerald Pfeifer 2016-08-11 13:42:41 UTC

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.

Comment 5 Kubilay Kocak 2016-08-13 12:52:42 UTC

*** Bug 210122 has been marked as a duplicate of this bug. ***

Comment 6 Kubilay Kocak 2016-08-13 12:53:49 UTC

Re-open pending resolution (commit/merge) of other gcc ports

Comment 7 commit-hook 2016-08-13 20:44:38 UTC

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

Comment 8 commit-hook 2016-08-14 07:28:22 UTC

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

Comment 9 Kubilay Kocak 2016-08-14 09:52:04 UTC

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.

Comment 10 Kubilay Kocak 2016-08-14 10:43:24 UTC

Link "same issue different port" bug 210122 so people can find it (technical duplicate but tracked separately)

Comment 11 Gerald Pfeifer 2016-08-14 11:03:17 UTC

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

Comment 12 Kubilay Kocak 2016-08-14 11:59:41 UTC

(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

Comment 13 Gerald Pfeifer 2016-08-14 12:10:35 UTC

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

Comment 14 Kubilay Kocak 2016-08-14 12:39:32 UTC

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

Comment 15 John Marino 2016-08-14 16:09:26 UTC

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.

Comment 16 Mark Felder 2016-08-15 13:58:32 UTC

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

Comment 17 Kubilay Kocak 2016-08-15 14:37:47 UTC

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

Comment 18 Mark Felder 2016-08-15 15:24:55 UTC

This makes sense, thanks koobs

Comment 19 John Marino 2016-08-15 15:38:42 UTC

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.

Comment 20 commit-hook 2016-08-16 07:21:14 UTC

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

Comment 21 commit-hook 2016-08-17 09:03:28 UTC

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

Comment 22 commit-hook 2016-08-17 16:23:20 UTC

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

Comment 23 commit-hook 2016-08-22 13:21:23 UTC

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

Comment 24 Gerald Pfeifer 2016-08-22 13:31:32 UTC

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

Comment 25 Kubilay Kocak 2016-09-11 11:28:28 UTC

@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.

Comment 26 Gerald Pfeifer 2017-01-15 21:28:17 UTC

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