
Dear hackers,

It seems that current cvs head regression tests are broken, at least on my 
debian laptop. That does not help with developping some new patch...

sh> uname -a
Linux sablons 2.4.20-3-686 #1 Sat Jun 7 22:34:55 EST 2003 i686 GNU/Linux
sh> ./configure
sh> make
sh> cd src/test/regress
sh> make check
test errors               ... FAILED
      rules                ... FAILED
=======================
  2 of 95 tests failed.
=======================
sh> more log/postmaster.log
[...]
LOG:  unexpected EOF on client connection
LOG:  unexpected EOF on client connection
many more....
[...]

sh> more regressions.diffs
[...]
! /home/coelho/MISC/PGSQL/pgsql-sync/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql: relocation error: /home/coelho/MISC/PGSQL/pgsql-sync/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql: undefined symbol: pg_strcasecmp


-- 
Fabien Coelho - coelho@cri.ensmp.fr

Tue, 8 Jun 2004 15:53:51 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr>
cvs head : broken regression tests ?
Fabien COELHO wrote:
> 
> Dear hackers,
> 
> It seems that current cvs head regression tests are broken, at least on my 
> debian laptop. That does not help with developping some new patch...
> 
> sh> uname -a
> Linux sablons 2.4.20-3-686 #1 Sat Jun 7 22:34:55 EST 2003 i686 GNU/Linux
> sh> ./configure
> sh> make
> sh> cd src/test/regress
> sh> make check
> test errors               ... FAILED
>       rules                ... FAILED
> =======================
>   2 of 95 tests failed.
> =======================
> sh> more log/postmaster.log
> [...]
> LOG:  unexpected EOF on client connection
> LOG:  unexpected EOF on client connection
> many more....
> [...]
> 
> sh> more regressions.diffs
> [...]
> ! /home/coelho/MISC/PGSQL/pgsql-sync/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql: relocation error: /home/coelho/MISC/PGSQL/pgsql-sync/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql: undefined symbol: pg_strcasecmp

You get this error, pg_strcasecmp, when you have a different libpgport
library around instead of the CVS version.  You need to clean something
out to fix it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 8 Jun 2004 10:07:52 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs head : broken regression tests ?
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> It seems that current cvs head regression tests are broken, at least on my 
> debian laptop. That does not help with developping some new patch...

FWIW, I've seen no such problems...

			regards, tom lane

Tue, 08 Jun 2004 10:46:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs head : broken regression tests ? 

> You get this error, pg_strcasecmp, when you have a different libpgport 
> library around instead of the CVS version.  You need to clean something 
> out to fix it.

Isn't the "make check" supposed to used the new version of binaries and 
libraries?

I investigated a little bit following your hint:

Indeed, I already have a dev version installed in "/usr/local/pgsql". This 
libpq is used during tests by "psql" rather than the newly compiled one, 
despite the library path fix. I guess this is thanks to the 
"-Wl,-rpath,/usr/local/pgsql/lib" option used when linking "psql".

So it works if I do a "configure --prefix=<some-empty-directory>".

It means that you cannot expect a "make check" to work properly if you 
intend to install postgresql where a previous version is already 
installed. Let's call this a "feature";-)

-- 
Fabien Coelho - coelho@cri.ensmp.fr

Tue, 8 Jun 2004 18:09:45 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr>
Re: cvs head : broken regression tests ?
Fabien COELHO wrote:

>
>> You get this error, pg_strcasecmp, when you have a different 
>> libpgport library around instead of the CVS version.  You need to 
>> clean something out to fix it.
>
>
> Isn't the "make check" supposed to used the new version of binaries 
> and libraries?
>
> I investigated a little bit following your hint:
>
> Indeed, I already have a dev version installed in "/usr/local/pgsql". 
> This libpq is used during tests by "psql" rather than the newly 
> compiled one, despite the library path fix. I guess this is thanks to 
> the "-Wl,-rpath,/usr/local/pgsql/lib" option used when linking "psql".
>
> So it works if I do a "configure --prefix=<some-empty-directory>".
>
> It means that you cannot expect a "make check" to work properly if you 
> intend to install postgresql where a previous version is already 
> installed. Let's call this a "feature";-)
>

This only applies to dev versions, as the library version is bumped each 
release, I believe. IOW it's purely a developer's trap (which has caught 
me in the past). If you build and install multiple dev versions you 
should think about disabling rpath.

cheers

andrew

Tue, 08 Jun 2004 12:44:22 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: cvs head : broken regression tests ?
On Tue, Jun 08, 2004 at 12:44:22PM -0400, Andrew Dunstan wrote:

> This only applies to dev versions, as the library version is bumped each 
> release, I believe.

Actually, the library version is not bumped each release --- in fact,
there has been at least one time in the past where the version _should_
have been bumped and it wasn't.

> IOW it's purely a developer's trap (which has caught me in the past).
> If you build and install multiple dev versions you should think about
> disabling rpath.

I do that, and I have rpath enabled (that's the default, isn't it?) but
my solution is to have no version in normal directories (i.e. they are
all installed in $HOME/pgsql/some-version-number/ )

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Crear es tan difï¿½cil como ser libre" (Elsa Triolet)


Tue, 8 Jun 2004 13:30:18 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: cvs head : broken regression tests ?
Alvaro Herrera wrote:

>>IOW it's purely a developer's trap (which has caught me in the past).
>>If you build and install multiple dev versions you should think about
>>disabling rpath.
>>    
>>
>
>I do that, and I have rpath enabled (that's the default, isn't it?) but
>my solution is to have no version in normal directories (i.e. they are
>all installed in $HOME/pgsql/some-version-number/ )
>
>  
>


If this is the prefix you specify to configure you can still get caught 
when you do a cvs update and then run "make check" before "make 
install". Turning off rpath stops that (at least on my Linux boxes).

cheers

andrew


Tue, 08 Jun 2004 14:03:05 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: cvs head : broken regression tests ?
On Tue, Jun 08, 2004 at 02:03:05PM -0400, Andrew Dunstan wrote:
> Alvaro Herrera wrote:
> 
> >I do that, and I have rpath enabled (that's the default, isn't it?) but
> >my solution is to have no version in normal directories (i.e. they are
> >all installed in $HOME/pgsql/some-version-number/ )
> 
> If this is the prefix you specify to configure you can still get caught 
> when you do a cvs update and then run "make check" before "make 
> install". Turning off rpath stops that (at least on my Linux boxes).

Hm, you may be right, but I haven't noticed because I haven't done that
yet.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Jason Tesser: You might not have understood me or I am not understanding you.
Paul Thomas: It feels like we're 2 people divided by a common language...


Tue, 8 Jun 2004 19:17:48 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: cvs head : broken regression tests ?
Alvaro Herrera wrote:
> On Tue, Jun 08, 2004 at 12:44:22PM -0400, Andrew Dunstan wrote:
> 
> > This only applies to dev versions, as the library version is bumped each 
> > release, I believe.
> 
> Actually, the library version is not bumped each release --- in fact,
> there has been at least one time in the past where the version _should_
> have been bumped and it wasn't.

I am not sure the version bump would even help because we only bump the
minor version (unless we change the API), and I thought things go for
the highest minor numberred lib with the same major version.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 8 Jun 2004 19:37:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs head : broken regression tests ?
Andrew Dunstan <andrew@dunslane.net> writes:
> This only applies to dev versions, as the library version is bumped each 
> release, I believe.

Bumping the minor version number is part of Bruce's standard per-release
checklist.  However, it seems to me that there are some popular
platforms (eg Linux) where a minor version increment isn't really
noticed by the dynamic linker, and only a bump in the major version
number is sufficient to dissuade the linker from seizing on an older
version of the shared library.

Bumping the major version on each release doesn't sound great either,
as it would create binary incompatibility whether we needed it or not.

Anyone see a decent compromise?

			regards, tom lane

Wed, 09 Jun 2004 00:53:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs head : broken regression tests ? 