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.*

Reply via email to