The traf_tools_setup.sh script has not changed in the in the last few days. I hope that the download location for thrift have not changed. The only thing I can see that has been changing is the wiki instructions for setting up the environment.
I see at least one thing wrong on wiki. For instance, it says that CentOS 6.7 won't work. That is not correct. There was a mistaken impression that 6.7 has newer gcc. Not true. With the very latest code (as of this morning), the qt-devel and qt-config should no longer be needed. --Steve > -----Original Message----- > From: Gunnar Tapper [mailto:tapper.gun...@gmail.com] > Sent: Monday, March 7, 2016 2:03 PM > To: dev@trafodion.incubator.apache.org > Subject: Re: Parallel Make Failures > > Alas, things are getting worse rather than better... :( > > I create a new VM, installed all required packages, did a git clone of > trafodion, and then I ran install/traf_tools_setup.sh. Now, Thrift isn't > building the include and lib folders. I run the exact same command on the > version that I downloaded last Thursday and that works just fine. > > Did anything change that I should be aware of? > > Gunnar > > On Mon, Mar 7, 2016 at 12:17 PM, Gunnar Tapper > <tapper.gun...@gmail.com> > wrote: > > > Well, today, the build doesn't work at all regardless of what -j or -l > > options I use. It constantly fails on: > > > > Generating C++ code from yacc file ../sqlci/sqlci_yacc.y ##(SQL) > > ../sqlci/sqlci_yacc.y: warning: 1 reduce/reduce conflict > > [-Wconflicts-rr] > > ##(SQL) > > /home/centos/traf-tools/bison_3_linux/bin/bison: > > /home/centos/trafodion//bison_3_linux/share/bison/m4sugar/m4sugar.m4: > > cannot open: No such file or directory ##(SQL) > > mv: cannot stat `sqlcilib/linux/64bit/debug/sqlci_yacc.cpp': No such > > file > > or directory ##(SQL) > > sed: can't read sqlcilib/linux/64bit/debug/sqlci_yacc.cpp.tmp: No such > > file or directory ##(SQL) > > sed: can't read sqlcilib/linux/64bit/debug/sqlci_yacc.hpp: No such file > > or > > directory ##(SQL) > > rm: cannot remove `sqlcilib/linux/64bit/debug/sqlci_yacc.hpp': No such > > file or directory ##(SQL) > > rm: cannot remove `sqlcilib/linux/64bit/debug/sqlci_yacc.cpp.tmp': No > > such > > file or directory ##(SQL) > > make[4]: *** [sqlcilib/linux/64bit/debug/sqlci_yacc.h] Error 1 ##(SQL) > > make[4]: Leaving directory > > `/home/centos/incubator-trafodion/core/sql/nskgmake' ##(SQL) > > make[3]: *** [all] Error 2 ##(SQL) > > make[3]: Leaving directory > > `/home/centos/incubator-trafodion/core/sqf/sql' > > ##(SQL) > > make[2]: *** [make_sql] Error 2 > > make[2]: Leaving directory `/home/centos/incubator-trafodion/core/sqf' > > make[1]: *** [foundation] Error 2 > > make[1]: Leaving directory `/home/centos/incubator-trafodion/core' > > make: *** [all] Error 2 > > > > > > On Mon, Mar 7, 2016 at 12:05 PM, Amanda Moran > <amanda.mo...@esgyn.com> > > wrote: > > > >> On redhat 7.1 this command still works: > >> > >> [ec2-user@ip-10-0-0-175 ~]$ cat /etc/redhat-release > >> Red Hat Enterprise Linux Server release 7.1 (Maipo) > >> > >> [ec2-user@ip-10-0-0-175 ~]$ grep processor /proc/cpuinfo | wc -l > >> 4 > >> > >> > >> On Mon, Mar 7, 2016 at 9:56 AM, Steve Varnau <steve.var...@esgyn.com> > >> wrote: > >> > >> > > It seems that the parallel make fails on 8 GB machines. > >> > > >> > I think your first sentence overstates the determinism of the problem > >> > a > >> > bit. > >> > I ran a normal, default build on 8GB machine last week and had no > >> problem. > >> > There must be an environmental problem, but I don't think we fully > >> > understand it yet. > >> > > >> > The aggressiveness of the make parallelism is set in > >> core/sqf/sqenvcom.sh. > >> > It sets the parallel factor based on how many CPUs are on your > >> > machine: > >> > > >> > # Set default build parallelism > >> > # Can be overridden on make commandline > >> > cpucnt=$(grep processor /proc/cpuinfo | wc -l) > >> > # no number means unlimited, and will swamp the system > >> > export MAKEFLAGS="-j$cpucnt" > >> > > >> > If that calculation is wrong, maybe that could cause a problem. > >> > > >> > --Steve > >> > > >> > > >> > > -----Original Message----- > >> > > From: Gunnar Tapper [mailto:tapper.gun...@gmail.com] > >> > > Sent: Monday, March 7, 2016 9:35 AM > >> > > To: dev@trafodion.incubator.apache.org > >> > > Subject: Parallel Make Failures > >> > > > >> > > Hi, > >> > > > >> > > It seems that the parallel make fails on 8 GB machines. At least, > >> Nitin > >> > > and > >> > > I both ran into make failures that did not appear when running > >> > > serial > >> > > make. > >> > > I've also seen similar failures when building the code on 12 GB > >> machines. > >> > > > >> > > Based on previous discussions, the Trafodion Contributor Guide > >> recommends > >> > > rerunning make a few times if running issues. > >> > > > >> > > I most wonder if there's a way to reduce the aggressiveness of the > >> make > >> > in > >> > > general. Could we, for example, come up with a table that > >> > > correlates > >> > > system > >> > > size to define the -l option or something similar? > >> > > > >> > > -- > >> > > Thanks, > >> > > > >> > > Gunnar > >> > > *If you think you can you can, if you think you can't you're > >> > > right.* > >> > > >> > >> > >> > >> -- > >> Thanks, > >> > >> Amanda Moran > >> > > > > > > > > -- > > Thanks, > > > > Gunnar > > *If you think you can you can, if you think you can't you're right.* > > > > > > -- > Thanks, > > Gunnar > *If you think you can you can, if you think you can't you're right.*