> GIGO right - computers, given the same input should > produce the same output > every time. If it's garbage in it's garbage out. > > The build of sip4-tqt seems to violate that adage. > When attempt to build > sip4-tqt (the first time/randomly), I get a failure: > > gcc -c -march=i686 -mtune=generic -O2 -pipe > -fstack-protector > --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 > -I/usr/include/tqt > -I/opt/trinity/include -I/opt/tqt3/include -O2 -w -DNDEBUG > -I. -o parser.o parser.c > lex -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu > -t lexer.l > lexer.c > /usr/bin/flex: Unrecognized option `W' > Try `flex --help' for more information. > make[1]: *** [lexer.c] Error 1 > make[1]: Leaving directory `/build/src/sipPy3/sipgen' > make: *** [all] Error 2 > > The only 'W' that could be causing the error is the > LDFLAGS string > '-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu', > but that hasn't > caused a problem before so I just issue the build command > again - and it builds > without issue - WTF? > > Looking at the lex command above I see: > > lex -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu > -t lexer.l > lexer.c > > That doesn't seem right. I don't know lex from fred, > passing 'lex ${LDFLAGS} > -t lexer.l > lexer.c' doesn't seem right because there is > no '-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu' > c syntax that I > know of :) > > Has anyone else seen this spurious behavior? I kills > rebuilds when it causes > sip build failures > > I haven't changed a thing, and I get different > results. > > The build is simple: > > <snip> > cd ${srcdir} > > ## copy source for Python build > cp -r ${pkgbase#*-} sipPy3 > > ## Python version > msg "Running python configure.py (python3 based sip)...." > cd ${srcdir}/sipPy3 > python configure.py CFLAGS="${CFLAGS}" LFLAGS="${LDFLAGS}" > msg "Building - tde-sip (python3 based sip)..." > make > > ## Python2 version > msg "Running python2 configure.py (sip4-tqt)...." > cd ${srcdir}/${pkgbase#*-} > python2 configure.py CFLAGS="${CFLAGS}" LFLAGS="${LDFLAGS}" > msg "Building - ${pkgbase}..." > make > > } > > Any thoughts? > First thought is something is indeed changing. We just can't recognize what. Not yet. Second thought is I have seen this before --- several weeks ago with tdenetwork. For some reason I could not build tdenetwork during my first pass when I built all of my packages in one run with my master build script. The build always failed. Yet after the master build run completed, I could build tdenetwork without failure. Eventually I decided there was some weird relationship with tdeadmin, which I always had built just after tdenetwork. I reversed the order so that tdeadmin built before tdenetwork and I have not had a problem since. I have not tried to revert to the older order to test whether the problem remains. Possibly the problem is now gone, who knows. I notice you now are building two packages, one for python 2 and one for python 3. I suspect somewhere in that transition you'll find what you changed to cause the latest hair pulling. :) Darrell