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.
next prev 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: linkBe 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).