public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/92008] Build failure on cygwin
Date: Thu, 16 Apr 2020 09:55:56 +0000	[thread overview]
Message-ID: <bug-92008-4-KZ0qPXS9tC@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-92008-4@http.gcc.gnu.org/bugzilla/>

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.

  parent reply	other threads:[~2020-04-16  9:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-92008-4@http.gcc.gnu.org/bugzilla/>
2020-04-15  4:24 ` [Bug target/92008] " pinskia at gcc dot gnu.org
2020-04-15  4:26 ` [Bug bootstrap/92008] " pinskia at gcc dot gnu.org
2020-04-15  4:53 ` pinskia at gcc dot gnu.org
2020-04-15  4:54 ` euloanty at live dot com
2020-04-15  4:57 ` pinskia at gcc dot gnu.org
2020-04-15  9:18 ` jakub at gcc dot gnu.org
2020-04-15  9:54 ` rguenth at gcc dot gnu.org
2020-04-15 11:33 ` jakub at gcc dot gnu.org
2020-04-15 16:03 ` akim.demaille at gmail dot com
2020-04-16  8:13 ` cvs-commit at gcc dot gnu.org
2020-04-16  9:55 ` cvs-commit at gcc dot gnu.org [this message]
2020-04-16  9:59 ` akim.demaille at gmail dot com
2020-04-16 10:14 ` jakub at gcc dot gnu.org
2020-04-16 10:19 ` akim.demaille at gmail dot com
2020-04-16 10:21 ` akim.demaille at gmail dot com
2020-04-16 10:44 ` jakub at gcc dot gnu.org
2020-04-16 10:46 ` jakub at gcc dot gnu.org
2020-04-16 21:27 ` wilson at gcc dot gnu.org
2020-04-21  6:24 ` akim.demaille at gmail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-92008-4-KZ0qPXS9tC@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).