Thread: make check error on -HEAD
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm getting this error on two different servers, one if them is the server that I build PostgreSQL from CVS daily, the other one is a fresh one (used to double-check the error) Two servers have LANG="en_US.UTF-8". They are RHEL 3.0 Update 3 with gcc 3.2.3-42, and bison 1.875c: ====================================================================== ============== creating database "regression" ============== CREATE DATABASE pg_regress: could not set database default locales make[2]: *** [check] Error 2 rm regress.o make[2]: Leaving directory `/home/pgsql80/pgsql/src/test/regress' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/pgsql80/pgsql/src/test' make: *** [check] Error 2 ====================================================================== Any comments? 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) iD8DBQFBhMLwtl86P3SPfQ4RAibUAJ4h/gvrWr76FPjJvJRnGsF3TXEY/ACfWJ5d z+wKbSmMSgGaoBXCmeEX/gw= =3l/A -----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?
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, Pennsylvania19073
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