Ken Moffat wrote: > On Sun, Aug 11, 2013 at 07:25:20PM -0500, Bruce Dubbs wrote: >> Ken Moffat wrote: >>> On Sun, Aug 11, 2013 at 11:03:46PM +0100, Ken Moffat wrote: >>>> I haven't built a new system since April, so I thought it was time >>>> to test current -svn. In particular, I wanted to see how bison-3.0 >>>> impacted other packages. But I can't even build it! >>>> >>> Looks as if it is breaking bacause of one of my environment >>> variables - a plain build is ok. But then it builds ok (by hand) if >>> I dump the environment with printenv, export all the obvious >>> candidates, and then build by hand. >>> >>> I'll also note that when it does build by hand, the testsuite fails >>> with: >>> make[3]: Entering directory `/usr/src/bison-3.0' >>> YACC examples/calc++/calc++-parser.stamp >>> CXX examples/calc++/examples_calc___calc__-calc++-driver.o >>> LEX examples/calc++/calc++-scanner.cc >>> CXX examples/calc++/examples_calc___calc__-calc++-scanner.o >>> g++: error: ./examples/calc++/calc++-scanner.cc: No such file or >>> directory >> >> Now that's confusing. I have ./examples/calc++/calc++-scanner.cc and >> all those other files too. The timestamps do indicate that they are >> generated though. calc++-parser.stamp is an empty file. >> >> -rwxr-xr-x 1 root root 635267 Aug 11 22:09 calc++ >> -rw-r--r-- 1 root root 684 Aug 11 22:08 calc++-driver.cc >> -rw-r--r-- 1 root root 1195 Aug 11 22:08 calc++-driver.hh >> -rw-r--r-- 1 root root 28865 Aug 11 22:09 calc++-parser.cc >> -rw-r--r-- 1 root root 24999 Aug 11 22:09 calc++-parser.hh >> -rw-r--r-- 1 root root 7785 Aug 11 22:09 calc++-parser.output >> -rw-r--r-- 1 root root 0 Aug 11 22:09 calc++-parser.stamp >> -rw-r--r-- 1 root root 1812 Aug 11 22:08 calc++-parser.yy >> -rw-r--r-- 1 root root 52056 Aug 11 22:09 calc++-scanner.cc >> -rw-r--r-- 1 root root 1921 Aug 11 22:08 calc++-scanner.ll >> -rw-r--r-- 1 root root 469 Aug 11 22:08 calc++.cc >> -rw-r--r-- 1 root root 6045 Aug 11 22:09 calc++.log >> -rwxr-xr-x 1 505 20 958 Feb 20 17:33 calc++.test >> -rw-r--r-- 1 root root 82 Aug 11 22:09 calc++.trs >> -rw-r--r-- 1 root root 234464 Aug 11 22:09 >> examples_calc___calc__-calc++-driver.o >> -rw-r--r-- 1 root root 1076880 Aug 11 22:09 >> examples_calc___calc__-calc++-parser.o >> -rw-r--r-- 1 root root 190784 Aug 11 22:09 >> examples_calc___calc__-calc++-scanner.o >> -rw-r--r-- 1 root root 71032 Aug 11 22:09 examples_calc___calc__-calc++.o >> -rw-r--r-- 1 505 20 2900 Jun 11 14:36 local.mk >> -rw-r--r-- 1 root root 5126 Aug 11 22:09 location.hh >> -rw-r--r-- 1 root root 4894 Aug 11 22:09 position.hh >> -rw-r--r-- 1 root root 3530 Aug 11 22:09 stack.hh
> With the manual build, which got far enough for the tests to fail, > all I have is: > > root in chroot ~# ls -l /usr/src/bison-3.0/examples/calc++/ > total 28 > -rw-r--r-- 1 root root 684 Aug 12 00:08 calc++-driver.cc > -rw-r--r-- 1 root root 1195 Aug 12 00:08 calc++-driver.hh > -rw-r--r-- 1 root root 1812 Aug 12 00:08 calc++-parser.yy > -rw-r--r-- 1 root root 1921 Aug 12 00:08 calc++-scanner.ll > -rw-r--r-- 1 root root 469 Aug 12 00:08 calc++.cc > -rwxr-xr-x 1 505 20 958 Feb 20 17:33 calc++.test > -rw-r--r-- 1 505 20 2900 Jun 11 15:36 local.mk > root in chroot ~# > > But that is from the second problem (make check fails), and since I > can't build bison with my currrent scripts it isn't my main concerm. > > The failure to build seems to be a local problem (i.e. specific to > my scripts or environment). I was starting to wonder if the > currently running kernel (3.11-rc) might be involved, so I tried a > manual build on the host system, followed by make check : > > ## ------------- ## > ## Test results. ## > ## ------------- ## > > 409 tests were successful. > 23 tests were skipped. > make[3]: Leaving directory `/scratch/ken/bison-3.0' > > That looks good, so I guess that whatever is in the book is probably > fine - you maybe recall that I had a lot of problems with automake > tests in the past (into the 7.3 release, I think), caused by me > setting SCRIPTS in my buildscripts. This is probably something > similar (or maybe two similar things, since the tests don't work for > me in chroot even when run manually). Try adding a namespace, e.g. KM_SCRIPTS, to your environment variables. However, I suspect a problem in some package earlier in the build. > Perhaps it is time for me to stop pretending that I understand any > of this stuff, and just stick with bison-2.7.1 until that is no > longer adequate. That way, I won't have to dig out the patches to > fix things broken by bison-3.0. Mmm, *almost* sounds attractive :-) Well, later this week, we'll freeze LFS and at that point I'll start building all 700+ packages in BLFS. It helps that BLFS is up to date, but that should work out any Bison issues. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
