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

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

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

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

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)

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

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...

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

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