[Bug target/92008] Build failure on cygwin

[Bug target/92008] Build failure on cygwin

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |euloanty at live dot com

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 94601 has been marked as a duplicate of this bug. ***

[Bug bootstrap/92008] Build failure on cygwin

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like the problem is with Bison 3.0 and above with the internal intl
BASH has/had the same issue:
https://savannah.gnu.org/support/?109469

[Bug bootstrap/92008] Build failure on cygwin

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff

is more the correct fix.
Or use an older version of Bison.

[Bug bootstrap/92008] Build failure on cygwin

[euloanty at live dot com]

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

--- Comment #7 from fdlbxtqi <euloanty at live dot com> ---
(In reply to Andrew Pinski from comment #6)
> https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff
> 
> is more the correct fix.
> Or use an older version of Bison.

But I am using windows. So?? I should contact MSYS2 for fixing it?

[Bug bootstrap/92008] Build failure on cygwin

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to fdlbxtqi from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff
> > 
> > is more the correct fix.
> > Or use an older version of Bison.
> 
> But I am using windows. So?? I should contact MSYS2 for fixing it?

No, the fix is to include a similar fix to gcc sources.  The new intl sources
need to pick up to gcc sources.

[Bug bootstrap/92008] Build failure on cygwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Wouldn't it be better to git mv plural.y plural.y.in and depending on bison >=
3 or earlier just with sed tweak it (and in configure detect bison version, or
tweak it directly in configure)?
Use %lex-param/%parse-param in one case and YYLEX_PARAM/YYPARSE_PARAM.  Or any
other changes needed?
Having two almost identical files is a maintainance nightmare.

[Bug bootstrap/92008] Build failure on cygwin

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> Wouldn't it be better to git mv plural.y plural.y.in and depending on bison
> >= 3 or earlier just with sed tweak it (and in configure detect bison
> version, or tweak it directly in configure)?
> Use %lex-param/%parse-param in one case and YYLEX_PARAM/YYPARSE_PARAM.  Or
> any other changes needed?
> Having two almost identical files is a maintainance nightmare.

Agreed, tho requiring a new version wouldn't be my preference (it would break
build on SLES 12 based distros for IMHO no good reason - SLES 12 uses
bison 2.7).

Btw, with plural.y.in we have to be careful with release tarballs and
generated files in source since plural.y might then be newer than the
shipped plural.c.

[Bug bootstrap/92008] Build failure on cygwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-04-15
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48280
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48280&action=edit
gcc10-pr92008.patch

Lightly tested patch, both with bison 3.0.5 and 1.35.  As my target is
USE_INCLUDED_LIBINTL, intl normally doesn't build anything, but I've in each
case used make all-yes to actually build it and it builds fine with both bison
versions.  Whether it works properly at runtime I can't test easily though.

[Bug bootstrap/92008] Build failure on cygwin

[akim.demaille at gmail dot com]

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

Akim Demaille <akim.demaille at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |akim.demaille at gmail dot com

--- Comment #12 from Akim Demaille <akim.demaille at gmail dot com> ---
Hi all,

%parse-param was introduced in Bison version 1.875 (2003-01-01).  Do you really
need to maintain compatibility with even older versions of Bison?

What is fairly recent is that PARSE_PARAMS is no longer supported, not the
introduction of %parse-param and %lex-param.

[Bug bootstrap/92008] Build failure on cygwin

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2ca17e0a89ff6c37e17851a5bd7b0a03ee8de535

commit r10-7748-g2ca17e0a89ff6c37e17851a5bd7b0a03ee8de535
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 16 10:12:30 2020 +0200

    intl: Allow building both with old bison and bison >= 3 [PR92008]

    bison 3 apparently made a backwards incompatible change, dropped
    YYLEX_PARAM/YYPARSE_PARAM support and instead needs %param or %lex-param
    and %parse-param.  Furthermore, there is no easy way to conditionalize
    on bison version in the *.y files.
    While e.g. glibc bumped bison requirement and just has the bison 3
    compatible version, Richi said there are still systems with older bison
    where we want to build gcc.

    So, this patch instead determines during configure bison version, and
    depending on that when building plural.c (if building it at all) tweaks
    what is passed over to bison if needed.

    Tested with both bison 3 and bison 1.35, in each case with reconfiguring
    intl and building with make all-yes (as in my setup intl isn't normally
    used).

    2020-04-16  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/92008
            * configure.ac: Add check for bison >= 3, AC_DEFINE HAVE_BISON3
            and AC_SUBST BISON3_YES and BISON3_NO.
            * Makefile.in (.y.c): Prefix $(YACC) invocation with @BISON3_NO@,
            add @BISON3_YES@ prefixed rule to adjust the *.y source using sed
            and adjust output afterwards.
            * plural-exp.h (PLURAL_PARSE): If HAVE_BISON3 is defined, use
            struct parse_args * type for arg instead of void *.
            * plural.y: Add magic /* BISON3 ... */ comments with bison >= 3
            directives.
            (YYLEX_PARAM, YYPARSE_PARAM): Don't define if HAVE_BISON3 is
defined.
            (yylex, yyerror): Adjust prototypes and definitions if HAVE_BISON3
            is defined.
            * plural.c: Regenerated.
            * config.h.in: Regenerated.
            * configure: Regenerated.

[Bug bootstrap/92008] Build failure on cygwin

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:437eea66a4b010d8e94aa81c2b40ccf0588e5fab

commit r10-7752-g437eea66a4b010d8e94aa81c2b40ccf0588e5fab
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 16 11:55:00 2020 +0200

    intl: Unbreak intl build with bison 3 when no regeneration is needed
[PR92008]

    As Iain reported, my change broke the case when one has bison >= 3,
    but make decides there is no reason to regenerate plural.c, unfortunately
    that seems to be a scenario I haven't tested.  The problem is that
    the pregenerated plural.c has been generated with bison 1.35, but when
    config.h says HAVE_BISON3, the code assumes it is the bison3 variant.
    What used to work fine is when one has bison >= 3 and plural.c has been
    regenerated (e.g. do touch intl/plural.y and it will work), or when
    one doesn't have any bison (then nothing is regenerated, but HAVE_BISON3
    isn't defined either), or when one has bison < 3 and doesn't need to
    regenerate, or when one has bison < 3 and it is regenerated.

    The following patch fixes this, by killing the HAVE_BISON3 macro from
    config.h, and instead remembering the fact whether plural.c has been
created
    with bison < 3 or bison >= 3 in a separate new plural-config.h header.
    The way this works:
    - user doesn't have bison
    - user has bison >= 3, but intl/{plural-config.h,plural.c} aren't older
than intl/plural.y
    - user has bison < 3, but intl/{plural-config.h,plural.c} aren't older than
intl/plural.y
            pregenerated !USE_BISON3 plural.c and plural-config.h from source
            dir is used, nothing in the objdir
    - user has bison >= 3 and intl/plural.y is newer
            Makefile generates plural.c and USE_BISON3 plural-config.h in the
            objdir, which is then used in preference to srcdir copies
    - user has bison < 3 and intl/plural.y is newer
            Makefile generates plural.c and !USE_BISON3 plural-config.h in the
            objdir, which is then used in preference to srcdir copies
    I have tested all these cases and make all-yes worked in all the cases.
    If one uses the unsupported ./configure where srcdir == objdir, I guess
    (though haven't tested) that it should still work, just it would be nice
    if such people didn't try to check in the plural{.c,-config.h} they have
    regenerated.
    What doesn't work, but didn't work before either (just tested gcc-9 branch
    too) is when one doesn't have bison and plural.y is newer than plural.c.
    Don't do that ;)

    2020-04-16  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/92008
    intl/
            * configure.ac: Remove HAVE_BISON3 AC_DEFINE.
            * Makefile.in (HEADERS): Add plural-config.h.
            (.y.c): Also create plural-config.h.
            (dcigettext.o loadmsgcat.o plural.o plural-exp.o): Also depend
            on plural-config.h.
            (plural-config.h): Depend on plural.c.
            * plural-exp.h: Include plural-config.h.  Use USE_BISON3 instead
            of HAVE_BISON3.
            * plural.y: Use USE_BISON3 instead of HAVE_BISON3.
            * configure: Regenerated.
            * plural.c: Regenerated.
            * config.h.in: Regenerated.
            * plural-config.h: Generated.
    contrib/
            * gcc_update: Add intl/plural.y dependency for
intl/plural-config.h.

[Bug bootstrap/92008] Build failure on cygwin

[akim.demaille at gmail dot com]

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

--- Comment #15 from Akim Demaille <akim.demaille at gmail dot com> ---
Sorry to insist, but I don't understand all these complications.  Bison has
been supporting %parse-param for 17 years.

[Bug bootstrap/92008] Build failure on cygwin

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
bison 1.35 doesn't, and that is what has been used last time.
Is even %define api.pure full (vs. %pure_parser) supported in much older bison
versions?  Maybe 1.875 is the oldest people do use in real-world, not sure.
Requiring bison 3 or later only is unacceptable right now.

[Bug bootstrap/92008] Build failure on cygwin

[akim.demaille at gmail dot com]

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

--- Comment #17 from Akim Demaille <akim.demaille at gmail dot com> ---
Hi Jakub,

I'm not claiming you should require 3.0, I'm claiming there's no reason to
target 1.35, there is no evidence there's a need for it.  So there's no reason
to pay for "PARSE_PARAMS" support.

"%require" was introduced in 2.2 (2006-05-19).  Even Apple ships 2.3, stuck to
the last GPLv2 release.  So I suggest that you add "%require 2.2" and just use
%parse-param.  

But if you think 2.2 is too much to ask for, just use %parse-param (Bison
1.875).

Cheers!

[Bug bootstrap/92008] Build failure on cygwin

[akim.demaille at gmail dot com]

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

--- Comment #18 from Akim Demaille <akim.demaille at gmail dot com> ---
WRT to "pure-parser", there seems to be some misunderstanding.  News of 3.4
says:

  The %pure-parser directive is deprecated in favor of '%define api.pure'
  since Bison 2.3b (2008-05-27), but no warning was issued; there is one
  now.  Note that since Bison 2.7 you are strongly encouraged to use
  '%define api.pure full' instead of '%define api.pure'.

It does not say "%pure-parser is no longer supported"!

[Bug bootstrap/92008] Build failure on cygwin

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48287&action=edit
gcc10-pr92008.patch

Or maybe just do require bison 3 (7 years old) if intl/plural.y needs to be
regenerated?
Disadvantage is that people who don't use contrib/gcc_update --touch and do end
up with intl/plural.c newer and have older bison will get an error (guess not
an
issue in release tarballs, because there we through gcc_update --touch ensure
the timestamps are ok).

[Bug bootstrap/92008] Build failure on cygwin

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Forgot an important part:
--- config/gettext.m4.jj        2020-01-12 11:54:35.753423366 +0100
+++ config/gettext.m4   2020-04-16 12:34:51.466081569 +0200
@@ -1,5 +1,5 @@
 # gettext.m4 serial 20 (gettext-0.12)
-dnl Copyright (C) 1995-2003 Free Software Foundation, Inc.
+dnl Copyright (C) 1995-2020 Free Software Foundation, Inc.
 dnl This file is free software, distributed under the terms of the GNU
 dnl General Public License.  As a special exception to the GNU General
 dnl Public License, this file may be distributed as part of a program
@@ -380,7 +380,7 @@ __fsetlocking])

   dnl intl/plural.c is generated from intl/plural.y. It requires bison,
   dnl because plural.y uses bison specific features. It requires at least
-  dnl bison-1.26 because earlier versions generate a plural.c that doesn't
+  dnl bison-3 because earlier versions generate a plural.c that doesn't
   dnl compile.
   dnl bison is only needed for the maintainer (who touches plural.y). But in
   dnl order to avoid separate Makefiles or --enable-maintainer-mode, we put
@@ -398,7 +398,7 @@ changequote(<<,>>)dnl
     ac_prog_version=`$INTLBISON --version 2>&1 | sed -n 's/^.*GNU Bison.*
\([0-9]*\.[0-9.]*\).*$/\1/p'`
     case $ac_prog_version in
       '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
-      1.2[6-9]* | 1.[3-9][0-9]* | [2-9].*)
+      [3-9].*)
 changequote([,])dnl
          ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
       *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;

Or perhaps keep what is in the trunk right now for GCC 10 and do it only for
GCC11.

[Bug bootstrap/92008] Build failure on cygwin

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #21 from Jim Wilson <wilson at gcc dot gnu.org> ---
This looks the same as a binutils bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=22941

The easy solution is to touch intl/plural.c after checkout, so that bison won't
be run.  The contrib/gcc_update script already does this.  So the simplest
solution for the original problem is to use contrib/gcc_update to update a gcc
tree, or "contrib/gcc_update --touch" if you want to fix a gcc tree without
updating it.  If your gcc git source tree was already mangled by a bad bison
run, you will have to manually reset it to a clean tree, e.g. "git reset
--hard" or "git diff > tmp.file; patch -p1 --reverse < tmp.file; rm tmp.file"
or whatever, and then run the contrib/gcc_update --touch command.  Binutils
unfortunately does not have an equivalent to the gcc_update script and hence
requires a fix.

git unfortunately does not preserve file timestamps across commit and checkout,
so when you checkout a file it gets the current time.  git also tends to check
out files in alphabetical order.  If you are on a fast filesystem, i.e. linux,
plural.c and plural.y almost always get the same timestamp and bison isn't run.
 If you are on a slow filesystem, i.e. cygwin, plural.c is often older than
plural.y, and bison must be run, and the current bison version fails.  This is
why it is cygwin folk that most commonly run into this problem.

[Bug bootstrap/92008] Build failure on cygwin

[akim.demaille at gmail dot com]

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

--- Comment #22 from Akim Demaille <akim.demaille at gmail dot com> ---
FWIW, the version in the glibc was updated to use "%parse-params" and "%define
api.pure full" five years ago.

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=intl/plural.y;hb=6d248857845aee307440a77062a93b167cd2ac9c

That was part of a massive update from the genuine source, gettext.

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6d248857845aee307440a77062a93b167cd2ac9c