Thread: HEAD: Compile issues on UnixWare 7.1.4
Trying to set up my 7.1.4 box as a buildfarm member, and can't get through A build. The latest failure (after removing --with-perl) is: $ tail -20 ../../../lastrun-logs/make-contrib.log cc -O -Kinline -g -K PIC -I. -I../../src/include -I/usr/local/include -c -o seg.o seg.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled bison -y -d -p seg_yy segparse.y mv -f y.tab.c segparse.c mv -f y.tab.h segparse.h /usr/local/bin/flex -o'segscan.c' segscan.l cc -O -Kinline -g -K PIC -I. -I../../src/include -I/usr/local/include -c -o segparse.o segparse.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ar crs libseg.a `lorder seg.o segparse.o | tsort` tsort: -: input contains a loop: tsort: seg.o tsort: segparse.o UX:ar: ERROR: Incorrect usage UX:ar: TO FIX: Usage: ar [-V?] -key[arg] [posname] afile [name ...] where key[arg] is one of the following: r[uabi], m[abi], d, q, t, p, x[CT] gmake[1]: *** [libseg.a] Error 1 gmake[1]: Leaving directory `/pg-farm/farm/HEAD/pgsql.388/contrib/seg' gmake: *** [all] Error 2 $ I'm not sure what we're doing wrong. Ideas? (I saw similar stuff with perl, but...). I've got a REL8_0_STABLE run running now (should work, unless something is REALLY broken). Did the build system change between 8.0 and HEAD? Thanks! LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
"Larry Rosenman" <ler@lerctr.org> writes:
> Did the build system change between 8.0 and HEAD?
I don't think so --- certainly there are no changes in template/unixware
or makefiles/Makefile.unixware, which is where you'd expect to find any
platform-specific stuff. The ar command being complained of looks
pretty standard, if old-fashioned ... also, I'm pretty sure that similar
commands appear in the main build, long before you get to contrib.
Weird...
regards, tom lane
Larry Rosenman wrote: > Trying to set up my 7.1.4 box as a buildfarm member, and can't get > through A build. The latest failure (after removing --with-perl) is: > > $ tail -20 ../../../lastrun-logs/make-contrib.log > cc -O -Kinline -g -K PIC -I. -I../../src/include > -I/usr/local/include -c -o seg.o seg.c > UX:cc: WARNING: debugging and optimization mutually exclusive; -O > disabled bison -y -d -p seg_yy segparse.y mv -f y.tab.c segparse.c > mv -f y.tab.h segparse.h /usr/local/bin/flex -o'segscan.c' segscan.l > cc -O -Kinline -g -K PIC -I. -I../../src/include > -I/usr/local/include -c -o segparse.o segparse.c UX:cc: WARNING: > debugging and optimization mutually exclusive; -O disabled ar crs > libseg.a `lorder seg.o segparse.o | tsort` > tsort: -: input contains a loop: > > tsort: seg.o > tsort: segparse.o > UX:ar: ERROR: Incorrect usage > UX:ar: TO FIX: Usage: ar [-V?] -key[arg] [posname] afile [name ...] > where key[arg] is one of the following: > r[uabi], m[abi], d, q, t, p, x[CT] > gmake[1]: *** [libseg.a] Error 1 > gmake[1]: Leaving directory `/pg-farm/farm/HEAD/pgsql.388/contrib/seg' > gmake: *** [all] Error 2 > $ > > I'm not sure what we're doing wrong. Ideas? > > (I saw similar stuff with perl, but...). > > I've got a REL8_0_STABLE run running now (should work, unless > something is REALLY broken). > > Did the build system change between 8.0 and HEAD? > > Thanks! > > > LER For the record I'm seeing the same failure on REL8_0_STABLE :( Anyone got any ideas? I can give access to the machine/account if needed. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
Tom Lane wrote: > "Larry Rosenman" <ler@lerctr.org> writes: >> Did the build system change between 8.0 and HEAD? > > I don't think so --- certainly there are no changes in > template/unixware or makefiles/Makefile.unixware, which is where > you'd expect to find any platform-specific stuff. The ar command > being complained of looks pretty standard, if old-fashioned ... also, > I'm pretty sure that similar commands appear in the main build, long > before you get to contrib. Weird... > > regards, tom lane It does. :(. I'll play some more, but I'm at a loss. Especially since REL8_0_STABLE fails as well :( Thanks. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
Larry Rosenman wrote: >I'll play some more, but I'm at a loss. Especially since REL8_0_STABLE >fails as well :( > > It was a PATH problem, as Larry discovered. With the patch I posted tonight both these branches run fine on Larry's machine (see below) FYI, I notice that, on this platform, on both HEAD and REL8_0_STABLE, the contrib/intarray tests run *extremely* slowly on both branches, apparently taking huge amounts of time over the last two gist index creation statements. It ran so slowly that I thought it was hung. cheers andrew bash-2.05a$ ./run_build.pl --verbose --nosend --nostatus --keepall REL8_0_STABLE checking out source ... checking if build run needed ... copying source to pgsql.12761 ... running configure ... running make ... running make check ... running make contrib ... running make install ... setting up db cluster ... starting db ... running make installcheck ... restarting db ... running make contrib install ... running make contrib installcheck ... stopping db ... OK Branch: REL8_0_STABLE All stages succeeded bash-2.05a$ ./run_build.pl --verbose --nosend --nostatus --keepall checking out source ... checking if build run needed ... copying source to pgsql.7066 ... running configure ... running make ... running make check ... running make contrib ... running make install ... setting up db cluster ... starting db ... running make installcheck ... restarting db ... running make PL installcheck ... restarting db ... running make contrib install ... running make contrib installcheck ... stopping db ... OK Branch: HEAD All stages succeeded bash-2.05a$
Andrew Dunstan <andrew@dunslane.net> writes:
> FYI, I notice that, on this platform, on both HEAD and REL8_0_STABLE,
> the contrib/intarray tests run *extremely* slowly on both branches,
> apparently taking huge amounts of time over the last two gist index
> creation statements. It ran so slowly that I thought it was hung.
intarray's regression test has always seemed pretty slow to me ...
are you sure there's something out of the ordinary here?
regards, tom lane