make check error on -HEAD

Devrim GUNDUZ <devrim@gunduz.org> writes:

pg_regress: could not set database default locales

What shows up in the postmaster log file?

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Sun, 31 Oct 2004, Tom Lane wrote:

pg_regress: could not set database default locales

What shows up in the postmaster log file?

You mean src/test/regress/log/postmaster.log, right?

Actually not that much:

LOG: database system was shut down at 2004-10-31 18:41:23 EET
LOG: checkpoint record is at 0/A30FE8
LOG: redo record is at 0/A30FE8; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 492; next OID: 17230
LOG: database system is ready
LOG: unexpected EOF on client connection
LOG: received fast shutdown request
LOG: shutting down
LOG: database system is shut down

Regards,
- --
Devrim GUNDUZ
devrim~gunduz.org devrim.gunduz~linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBhRi8tl86P3SPfQ4RAjYeAKC75B6SPdZUR8SNZ1nOu5cXQZ1S1ACfbUhx
rSL56HYBFmpltjTEF3s2SQQ=
=vZ60
-----END PGP SIGNATURE-----

Devrim GUNDUZ <devrim@gunduz.org> writes:

pg_regress: could not set database default locales

What shows up in the postmaster log file?

You mean src/test/regress/log/postmaster.log, right?
Actually not that much:

LOG: unexpected EOF on client connection

Hmm, that seems to be the only sign of trouble, which I guess means we
have to conclude the problem is on the client side not the server side.
The part of the pg_regress script that is failing is evidently

"$bindir/psql" $psql_options -c "\
checkpoint;
alter database \"$dbname\" set lc_messages to 'C';
alter database \"$dbname\" set lc_monetary to 'C';
alter database \"$dbname\" set lc_numeric to 'C';
alter database \"$dbname\" set lc_time to 'C';" "$dbname" 2>/dev/null
if [ $? -ne 0 ]; then
echo "$me: could not set database default locales"
(exit 2); exit
fi

Try removing the "2>/dev/null" bit so that you can see if any error
messages come out from psql.

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Sun, 31 Oct 2004, Tom Lane wrote:

LOG: unexpected EOF on client connection

Hmm, that seems to be the only sign of trouble, which I guess means we
have to conclude the problem is on the client side not the server side.
The part of the pg_regress script that is failing is evidently

"$bindir/psql" $psql_options -c "\
checkpoint;
alter database \"$dbname\" set lc_messages to 'C';
alter database \"$dbname\" set lc_monetary to 'C';
alter database \"$dbname\" set lc_numeric to 'C';
alter database \"$dbname\" set lc_time to 'C';" "$dbname" 2>/dev/null
if [ $? -ne 0 ]; then
echo "$me: could not set database default locales"
(exit 2); exit
fi

Try removing the "2>/dev/null" bit so that you can see if any error
messages come out from psql.

Ok, we have a detailed error now:

/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
relocation error:
/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
undefined symbol: PQgetCancel
pg_regress: could not set database default locales
make[2]: *** [check] Error 2
make[2]: Leaving directory `/home/pgsql80/pgsql/src/test/regress'

Regards,
- --
Devrim GUNDUZ
devrim~gunduz.org devrim.gunduz~linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBhR0utl86P3SPfQ4RAjbWAJ9HsRqk7uW2yZTUbI/i4Ds+nMW6aQCfXlzx
BI5pV37UYbKEjXgMxZSpfLY=
=Ocrg
-----END PGP SIGNATURE-----

Devrim GUNDUZ <devrim@gunduz.org> writes:

Try removing the "2>/dev/null" bit so that you can see if any error
messages come out from psql.

Ok, we have a detailed error now:

/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
relocation error:
/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
undefined symbol: PQgetCancel
pg_regress: could not set database default locales

Oh, so you are using yesterday's libpq.so shared library ;-)

I am not sure there is any way around that except to go ahead and
install today's libpq. pg_regress can't do much more than set
LD_LIBRARY_PATH, and evidently that's not enough to make the Linux
dynamic loader take the version of libpq.so that's in the temp
installation rather than the one you previously installed.

regards, tom lane

Tom Lane wrote:

Devrim GUNDUZ <devrim@gunduz.org> writes:

Try removing the "2>/dev/null" bit so that you can see if any error
messages come out from psql.

Ok, we have a detailed error now:

/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
relocation error:
/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
undefined symbol: PQgetCancel
pg_regress: could not set database default locales

Oh, so you are using yesterday's libpq.so shared library ;-)

I am not sure there is any way around that except to go ahead and
install today's libpq. pg_regress can't do much more than set
LD_LIBRARY_PATH, and evidently that's not enough to make the Linux
dynamic loader take the version of libpq.so that's in the temp
installation rather than the one you previously installed.

Yep, I saw the same thing here and make install fixed 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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Oh, so you are using yesterday's libpq.so shared library ;-)

I am not sure there is any way around that except to go ahead and
install today's libpq. pg_regress can't do much more than set
LD_LIBRARY_PATH, and evidently that's not enough to make the Linux
dynamic loader take the version of libpq.so that's in the temp
installation rather than the one you previously installed.

Yep, I saw the same thing here and make install fixed it.

I looked at this a bit more and found that on Linux, the dynamic
loader is documented to search "rpath" before LD_LIBRARY_PATH;
so had we not specified an rpath when building the psql executable,
pg_regress would have worked as intended. Sounds like BSD is the same.

Now, not specifying rpath seems like a sure loss for every context
except "make check" with an uninstalled version. So I'm afraid we have
to live with it. It might be worthwhile for build-farm builds to use
"configure --disable-rpath", if they want to "make check" without
installing first.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Oh, so you are using yesterday's libpq.so shared library ;-)

I am not sure there is any way around that except to go ahead and
install today's libpq. pg_regress can't do much more than set
LD_LIBRARY_PATH, and evidently that's not enough to make the Linux
dynamic loader take the version of libpq.so that's in the temp
installation rather than the one you previously installed.

Yep, I saw the same thing here and make install fixed it.

I looked at this a bit more and found that on Linux, the dynamic
loader is documented to search "rpath" before LD_LIBRARY_PATH;
so had we not specified an rpath when building the psql executable,
pg_regress would have worked as intended. Sounds like BSD is the same.

Now, not specifying rpath seems like a sure loss for every context
except "make check" with an uninstalled version. So I'm afraid we have
to live with it. It might be worthwhile for build-farm builds to use
"configure --disable-rpath", if they want to "make check" without
installing first.

The build-farm script removes the installation directory (we don't use
the default, of course) after each run, so the library won't ever be
found in the rpath during "make check", regardless of this setting.

cheers

andrew

On Mon, 2004-11-01 at 07:51, Tom Lane wrote:

I looked at this a bit more and found that on Linux, the dynamic
loader is documented to search "rpath" before LD_LIBRARY_PATH;
so had we not specified an rpath when building the psql executable,
pg_regress would have worked as intended. Sounds like BSD is the same.

Seems Solaris does it the other way:

http://list-archive.xemacs.org/xemacs-beta/200001/msg00328.html

although Drepper says in the thread that searching rpath before
LD_LIBRARY_PATH is per standard.

Now, not specifying rpath seems like a sure loss for every context
except "make check" with an uninstalled version. So I'm afraid we have
to live with it.

This is a kludge, but could we specify LD_PRELOAD?

-Neil

Tom Lane wrote:

Devrim GUNDUZ <devrim@gunduz.org> writes:

Try removing the "2>/dev/null" bit so that you can see if any error
messages come out from psql.

Ok, we have a detailed error now:

/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
relocation error:
/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
undefined symbol: PQgetCancel
pg_regress: could not set database default locales

Oh, so you are using yesterday's libpq.so shared library ;-)

I am not sure there is any way around that except to go ahead and
install today's libpq. pg_regress can't do much more than set
LD_LIBRARY_PATH, and evidently that's not enough to make the Linux
dynamic loader take the version of libpq.so that's in the temp
installation rather than the one you previously installed.

I have just seen this failure on Windows - it appears to have nothing to
do there with finding an out of date libpq.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

pg_regress: could not set database default locales

I have just seen this failure on Windows - it appears to have nothing to
do there with finding an out of date libpq.

Actually, *any* failure in pg_regress's first attempt to invoke psql
yields this message. I tweaked the script yesterday to not suppress
stderr; do you have that update yet?

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

pg_regress: could not set database default locales

I have just seen this failure on Windows - it appears to have nothing to
do there with finding an out of date libpq.

Actually, *any* failure in pg_regress's first attempt to invoke psql
yields this message. I tweaked the script yesterday to not suppress
stderr; do you have that update yet?

Yes, but on Windows it doesn't give anything on stderr, it gives me a
nasty popup with no useful info I can see, and wants to send info off to
microsoft.

cheers

andrew