Buildfarm failure on ecpg/test/pgtypeslib

Jim C. Nasby wrote:

Platypus just started failing...
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01

Rest of the farm is looking pretty green, though, so I'm not sure what
to make of it... but
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2009:05:01
is the first run it failed on, and several files changed in ecpg/test:

Files changed this run

pgsql/src/interfaces/ecpg/ChangeLog 1.320
pgsql/src/interfaces/ecpg/include/pgtypes_numeric.h 1.16
pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c 1.2
pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.stdout 1.2
pgsql/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc 1.2
pgsql/src/interfaces/ecpg/pgtypeslib/numeric.c 1.29

Also, it looks like "Files changed since last sucess" maybe isn't
working right? Or does it intentionally exclude files already listed in
"changed since last run"?

Jim, can you upgrade your version of the script to the latest in CVS?

http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pgbuildfarm/client-code/run_build.pl?rev=1.64&content-type=text/plain

It has a feature that blows away the ccache directory on failure, so
that we don't have a failure that might be caused by ccache persisting.

After that, remove the actual cache.( I notice that you are using ccache
but don't seem to have a cache directory set - that can be a problem,
too. It's best to have a cache per branch)

Alternatively, just turn off use of ccache in your config file -
probably commenting out this line would suffice:

'CC' => 'ccache gcc -O3 -pipe'

And see if that fixes the problem.

cheers

andrew

On Wed, Aug 09, 2006 at 12:17:44PM -0400, Andrew Dunstan wrote:

Jim C. Nasby wrote:

Platypus just started failing...
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01

Rest of the farm is looking pretty green, though, so I'm not sure what
to make of it... but
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2009:05:01
is the first run it failed on, and several files changed in ecpg/test:

Files changed this run

pgsql/src/interfaces/ecpg/ChangeLog 1.320
pgsql/src/interfaces/ecpg/include/pgtypes_numeric.h 1.16
pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c 1.2
pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.stdout 1.2
pgsql/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc 1.2
pgsql/src/interfaces/ecpg/pgtypeslib/numeric.c 1.29

Also, it looks like "Files changed since last sucess" maybe isn't
working right? Or does it intentionally exclude files already listed in
"changed since last run"?

Jim, can you upgrade your version of the script to the latest in CVS?

http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pgbuildfarm/client-code/run_build.pl?rev=1.64&content-type=text/plain

It has a feature that blows away the ccache directory on failure, so
that we don't have a failure that might be caused by ccache persisting.

Doesn't seem to be working; the cache still had data after
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2019:59:17.

After that, remove the actual cache.( I notice that you are using ccache
but don't seem to have a cache directory set - that can be a problem,
too. It's best to have a cache per branch)

That seems kinda bunk, since ccache is normally used in a system-wide
setting.

Alternatively, just turn off use of ccache in your config file -
probably commenting out this line would suffice:

'CC' => 'ccache gcc -O3 -pipe'

And see if that fixes the problem.

Nope, no dice...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Jim C. Nasby wrote:

On Wed, Aug 09, 2006 at 12:17:44PM -0400, Andrew Dunstan wrote:

Jim C. Nasby wrote:

Platypus just started failing...
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01

Rest of the farm is looking pretty green, though, so I'm not sure what
to make of it... but
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2009:05:01
is the first run it failed on, and several files changed in ecpg/test:

Files changed this run

pgsql/src/interfaces/ecpg/ChangeLog 1.320
pgsql/src/interfaces/ecpg/include/pgtypes_numeric.h 1.16
pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c 1.2
pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.stdout 1.2
pgsql/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc 1.2
pgsql/src/interfaces/ecpg/pgtypeslib/numeric.c 1.29

Also, it looks like "Files changed since last sucess" maybe isn't
working right? Or does it intentionally exclude files already listed in
"changed since last run"?

Jim, can you upgrade your version of the script to the latest in CVS?

http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pgbuildfarm/client-code/run_build.pl?rev=1.64&content-type=text/plain

It has a feature that blows away the ccache directory on failure, so
that we don't have a failure that might be caused by ccache persisting.

Doesn't seem to be working; the cache still had data after
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2019:59:17.

*ahem* you loaded 1.62 (the latest release), not 1.64 (cvs tip) like I
asked.

After that, remove the actual cache.( I notice that you are using ccache
but don't seem to have a cache directory set - that can be a problem,
too. It's best to have a cache per branch)

That seems kinda bunk, since ccache is normally used in a system-wide
setting.

Not on my boxes! ;-) ccache is only used if explicitly invoked in my world.

Alternatively, just turn off use of ccache in your config file -
probably commenting out this line would suffice:

'CC' => 'ccache gcc -O3 -pipe'

And see if that fixes the problem.

Nope, no dice...

At any rate, do please try to blow the cache away manually and rerun.

btw, your config file also looks slightly out of date - a modern one
will set up a per branch cache, which is both safer and more effective.

cheers

andrew

Jim C. Nasby wrote:

Platypus just started failing...
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -I./../../include -I../../../../../src/interfaces/libpq -I../../include -I../../../../../src/include -L../../../../../src/port -L/usr/local/lib -Wl,-R'/home/buildfarm/buildfarm/HEAD/inst/lib' -L../../ecpglib -L../../pgtypeslib -L../../../libpq num_test2.c -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm -lpgtypes -lecpg -lpq -o num_test2
/tmp/buildfarm/ccwtFkAf.o(.text+0x259): In function `main':
/home/buildfarm/buildfarm/HEAD/pgsql.67800/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc:102: undefined reference to `PGTYPESdecimal_new'
/tmp/buildfarm/ccwtFkAf.o(.text+0x292):/home/buildfarm/buildfarm/HEAD/pgsql.67800/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc:118: undefined reference to `PGTYPESdecimal_free'
gmake[5]: *** [num_test2] Error 1

I note that both those functions exist in ecpg's pgtypeslib in HEAD
but not in 8.1. I'm betting you have an older pgtypeslib.so in
/usr/local/lib and that the poorly-chosen order of -L flags in the
above command is the problem.

Basically the bug here is that src/interfaces/ecpg/test/Makefile.regress
does

override LDFLAGS += -L../../ecpglib -L../../pgtypeslib -L../../../libpq

which is guaranteed to create the wrong ordering of -L switches compared
to anything coming from "configure --with-libraries". We need all the
-L switches for inside-the-build-tree directories to come before all the
ones for other places. pg_xs.mk does this by the simple expedient of
including PG_LIBS before LDFLAGS on the link command line;
Makefile.shlib has a more complex approach involving surgery on LDFLAGS
itself; but one way or the other you need to be careful.

regards, tom lane

On Wed, Aug 09, 2006 at 05:11:37PM -0400, Tom Lane wrote:

Jim C. Nasby wrote:

Platypus just started failing...
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-08-09%2010:05:01

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -I./../../include -I../../../../../src/interfaces/libpq -I../../include -I../../../../../src/include -L../../../../../src/port -L/usr/local/lib -Wl,-R'/home/buildfarm/buildfarm/HEAD/inst/lib' -L../../ecpglib -L../../pgtypeslib -L../../../libpq num_test2.c -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm -lpgtypes -lecpg -lpq -o num_test2
/tmp/buildfarm/ccwtFkAf.o(.text+0x259): In function `main':
/home/buildfarm/buildfarm/HEAD/pgsql.67800/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc:102: undefined reference to `PGTYPESdecimal_new'
/tmp/buildfarm/ccwtFkAf.o(.text+0x292):/home/buildfarm/buildfarm/HEAD/pgsql.67800/src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc:118: undefined reference to `PGTYPESdecimal_free'
gmake[5]: *** [num_test2] Error 1

I note that both those functions exist in ecpg's pgtypeslib in HEAD
but not in 8.1. I'm betting you have an older pgtypeslib.so in
/usr/local/lib and that the poorly-chosen order of -L flags in the
above command is the problem.

Basically the bug here is that src/interfaces/ecpg/test/Makefile.regress
does

override LDFLAGS += -L../../ecpglib -L../../pgtypeslib -L../../../libpq

which is guaranteed to create the wrong ordering of -L switches compared
to anything coming from "configure --with-libraries". We need all the
-L switches for inside-the-build-tree directories to come before all the
ones for other places. pg_xs.mk does this by the simple expedient of
including PG_LIBS before LDFLAGS on the link command line;
Makefile.shlib has a more complex approach involving surgery on LDFLAGS
itself; but one way or the other you need to be careful.

Makes sense, since the machine has an install of 8.1 out of FreeBSD
ports.

So... do we want something like

override LDFLAGS := $(LDFLAGS_NO_L) -L../../ecpglib -L../../pgtypeslib
-L../../../libpq

?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So... do we want something like
override LDFLAGS := $(LDFLAGS_NO_L) -L../../ecpglib -L../../pgtypeslib
-L../../../libpq

I suppose Michael and Joachim are in bed, so I'll try committing this.
If they don't like it they can fix it in the morning ...

regards, tom lane

On Wed, Aug 09, 2006 at 06:39:07PM -0400, Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So... do we want something like
override LDFLAGS := $(LDFLAGS_NO_L) -L../../ecpglib -L../../pgtypeslib
-L../../../libpq

I suppose Michael and Joachim are in bed, so I'll try committing this.
If they don't like it they can fix it in the morning ...

It just made it past contrib installcheck, so probably fixed.

BTW, what time does the anonymous-cvs rsync normally finish? Right now
my build starts at 5 after, but I suspect that's the worst possible time
for it...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

"Jim C. Nasby" <jnasby@pervasive.com> writes:

BTW, what time does the anonymous-cvs rsync normally finish? Right now
my build starts at 5 after, but I suspect that's the worst possible time
for it...

Marc recently said it starts at 19 after, so somewhere near half past is
probably the optimal time. (I'd suggest picking a random time near half
past, else all the buildfarm members will gang up on the server at once
...)

regards, tom lane

Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

BTW, what time does the anonymous-cvs rsync normally finish? Right now
my build starts at 5 after, but I suspect that's the worst possible time
for it...

Marc recently said it starts at 19 after, so somewhere near half past is
probably the optimal time. (I'd suggest picking a random time near half
past, else all the buildfarm members will gang up on the server at once
...)

is this also true of the cvsup server?

cheers

andrew

andrew@dunslane.net wrote:

is this also true of the cvsup server?

No, I think cvsup is served directly from the write-CVS. I've gotten
patches via CVSup that were just committed.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Wed, Aug 09, 2006 at 06:39:07PM -0400, Tom Lane wrote:

I suppose Michael and Joachim are in bed, so I'll try committing this.
If they don't like it they can fix it in the morning ...

Right we were. :-)

Thanks Tom.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Oh, I didn't realize there was a CVSup server. I think it'd be good
to promote that over CVS, as it's (supposedly) much easier on the
hosting machine.

Andrew, is there a way to get the buildfarm to use cvsup instead of
cvs? Does the script just call cvs via the shell?

On Aug 9, 2006, at 10:08 PM, Alvaro Herrera wrote:

andrew@dunslane.net wrote:

is this also true of the cvsup server?

No, I think cvsup is served directly from the write-CVS. I've gotten
patches via CVSup that were just committed.

--
Alvaro Herrera http://
www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of
broadcast)---------------------------
TIP 6: explain analyze is your friend

--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Jim Nasby wrote:

Oh, I didn't realize there was a CVSup server. I think it'd be good
to promote that over CVS, as it's (supposedly) much easier on the
hosting machine.

Andrew, is there a way to get the buildfarm to use cvsup instead of
cvs? Does the script just call cvs via the shell?

You can call cvs directly against your csvup repo copy if it's on the same
machine, or set up a pserver against the repo copy. The buildfarm howto at
http://pgfoundry.org/docman/view.php/1000040/4/PGBuildFarm-HOWTO.txt has
some extra details.

Buildfarm just calls your cvs client.

cheers

andrew