Re: r279278 failed to build (yacc: maximum table size exceeded)

On Feb 25, 2015, at 11:10, Jung-uk Kim <jkim_at_FreeBSD.org> wrote:

> Signed PGP part
> On 02/25/2015 13:55, Garrett Cooper wrote:
> > On Feb 25, 2015, at 10:51, Arseny Nasokin <eirnym_at_gmail.com>
> > wrote:
> >
> >> On 25 February 2015 at 20:27, Jung-uk Kim <jkim_at_freebsd.org>
> >> wrote:
> >>
> > On 02/25/2015 11:22, Ivan Klymenko wrote:
> >>>>> В Wed, 25 Feb 2015 15:43:27 +0000 Glen Barber
> >>>>> <gjb_at_FreeBSD.org> пишет:
> >>>>>
> >>>>>> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin
> >>>>>> wrote:
> >>>>>>> I have clean svn tree with base/head branch. I try to
> >>>>>>> build world, but I have some mysterious bugs. The
> >>>>>>> latest is yacc failed to make c file on phase 4.3:
> >>>>>>>
> >>>>>>> ===> usr.sbin/acpi/iasl (depend) m4 -P
> >>>>>>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
> >>>>>>>
> >>>>>>>
> >
> >>>>>>>
> > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
> >>>>>>>>
> >
> aslcompiler.y
> >>>>>>> yacc -d -pAslCompiler -oaslcompilerparse.c
> >>>>>>> aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f
> >>>>>>> - maximum table size exceeded *** Error code 2
> >>>>>>>
> >>>>>>> /etc/make.conf is /dev/null. I've also tried empty
> >>>>>>> /etc/src.conf with no luck.
> >>>>>>>
> >>>>>>
> >>>>>> Out of curiosity, is your src tree mounted via NFS?
> >>>>>>
> >>>>>> Glen
> >>>>>>
> >>>>>
> >>>>> I have a similar problem on revision /usr/src # svn info
> >>>>> Path: . Working Copy Root Path: /usr/src URL:
> >>>>> svn://svn.freebsd.org/base/head Relative URL: ^/head
> >>>>> Repository Root: svn://svn.freebsd.org/base Repository
> >>>>> UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213
> >>>>> Node Kind: directory Schedule: normal Last Changed Author:
> >>>>> glebius Last Changed Rev: 279213 Last Changed Date:
> >>>>> 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015)
> >>>>>
> >>>>> http://pastebin.com/FuAUkBmX
> >>>>>
> >>>>> Source tree is on the zfs /usr/src # zfs list zroot/usr/src
> >>>>> NAME USED  AVAIL  REFER  MOUNTPOINT zroot/usr/src  1.35G
> >>>>> 408G  1.35G /usr/src
> >>>>>
> >>>>> what is most surprising, the same revision successfully
> >>>>> building for the other 2 computers, including amd64|zfs and
> >>>>> i386|ufs.
> >
> > Your installed yacc(1) is too old, i.e., your world was built from
> > head before r274460.  FYI, this commit fixes the above problem for
> > building from stable:
> >
> > https://svnweb.freebsd.org/changeset/base/278975
> >
> > For building from old head (pre-r274460), you have to manually
> > bootstrap yacc first, e.g., something like this:
> >
> > cd /usr/src/usr.bin/yacc make clean cleandepend make all && make
> > install make clean cleandepend cd /usr/src make buildworld
> >
> > Jung-uk Kim
> >>>
> >>
> >>
> >> Hi, guys,
> >>
> >> I've found the fix by forcing to add yacc(1) to bootstrap build.
> >>
> >> Makefile.inc1, line 1277:
> >>
> >> if ${BOOTSTRAPPING} < 1001506 _yacc=      lib/liby \
> >>
> >> change to:
> >>
> >> if ${BOOTSTRAPPING} < 1201506 ## It is for test purposes only!!!
> >> _yacc=      lib/liby \
> >
> > It takes a few seconds to build this on my laptop — can we just
> > explicitly turn this on to be sure we’re using the right thing?
> >
> > % (cd lib/liby; time sh -c 'make obj; make depend; make all')
> >
> > real    0m0.326s user    0m0.031s sys     0m0.111s
> >
> > % (cd usr.bin/yacc/; time sh -c 'make obj; make depend; make all')
> >
> > real    0m3.431s user    0m2.631s sys     0m0.363s
> >
> > With me parallelizing bootstrap-tools on HEAD it should be less of
> > an issue stacking on items like this.
> 
> Then, this argument also applies to other conditional bootstrap-tools,
> e.g., bin/cat.
> 
> I know we have long tradition of painting bikesheds with different
> colors and it will probably never end.  However, I will not
> participate in this one, sorry.

I was going to propose something a bit more radical — I can remove the BOOTSTRAPPING conditionals and simplify the code on 10-STABLE / 11-CURRENT.

Maintaining BOOTSTRAPPING is error prone and it’s not saving much time in the long run in builds (it's taking longer to diagnose issues, test them, and commit fixes which will break at a later date). I’ve been bitten by this once because I don’t run ancient CURRENT/STABLE (r279198) and here are a couple follow up commits bumping tools versions in the past (e.g. r278975, r269662, etc).

Just a thought.