Thread: cvs head : broken regression tests ?
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
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, Pennsylvania19073
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, Pennsylvania19073
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