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