"make check" fails for 7.4.2 checked out from CVS

Hi all,

It's obviously something related to my system, as on a Suse box I made a
successful "make check" using the same code.
Still, do you have an idea what could be wrong with the Redhat system ?
As far as I know it doesn't have any non-standard things installed.

Thabks,
Csaba.

Csaba Nagy wrote:

I have checked out the REL7_4_2 version from the public CVS
repository, and running "make check" fails with:

Try running "make install" first or remove the existing installation.

Thanks to all who answered, finally it looks like Peter was right to the
point: I was compiling postgres with the same deployment prefix as the
installed (older) version, and probably there is some compiled in stuff
which accesses that directory even for the test server, and even if
that's not in the PATH.
Recompiling with a different prefix solved the problem, the check is
passing.
I wonder if this is a desirable effect ? I mean that the test suite is
not completely independent of what is installed ?

Thanks,
Csaba.

Dear Csaba ,

[snip]
/bin/sh ./pg_regress --temp-install --top-builddir=../../..
--schedule=./parallel_schedule --multibyte=SQL_ASCII
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 65432 with pid 29266
============== creating database "regression" ==============
/home/cnagy/dev/src/pgsql_7_4_2/src/test/regress/./tmp_check/install//opt/pgsql/bin/createdb: relocation error: /home/cnagy/dev/src/pgsql_7_4_2/src/test/regress/./tmp_check/install//opt/pgsql/bin/createdb: undefined symbol: get_progname
pg_regress: createdb failed

Check as follows :
1. Make sure you run gmkae check as PostgreSQL superuser.
2. Check that you are not out of disk space on the partition you are
"compiling" the server

Hope this helps

--
Best Regards,
Vishal Kashyap
Director / Lead Developer,
Sai Hertz And Control Systems Pvt Ltd,
http://saihertz.rediffblogs.com
Jabber IM: vishalkashyap@jabber.org
ICQ : 264360076
Yahoo IM: mailforvishal@yahoo.com
-----------------------------------------------
You yourself, as much as anybody in the entire
universe, deserve your love and affection.
- Buddha
---------------
pgsql=# select marital_status from vishals_life;

marital_status
------------------
Single not looking

1 Row(s) affected

___
//\\\
( 0_0 )
----------------o0o-----o0o---------------------

Csaba Nagy wrote:

I wonder if this is a desirable effect ? I mean that the test suite
is not completely independent of what is installed ?

You can't really avoid it unless you compile without embedded rpath.

Csaba Nagy <nagy@ecircle-ag.com> writes:

Thanks to all who answered, finally it looks like Peter was right to the
point: I was compiling postgres with the same deployment prefix as the
installed (older) version, and probably there is some compiled in stuff
which accesses that directory even for the test server, and even if
that's not in the PATH.
Recompiling with a different prefix solved the problem, the check is
passing.
I wonder if this is a desirable effect ? I mean that the test suite is
not completely independent of what is installed ?

The problem was that the new psql was linking to an older version of
libpq.so (one that doesn't export get_progname()). As best I can tell
that would have had to be a 7.3 libpq.so, which means there is something
wrong here because the 7.3 libpq should have had a different minor
number that would prevent the dynamic linker from accepting it as a
substitute. What platform are you using?

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

Csaba Nagy wrote:

I wonder if this is a desirable effect ? I mean that the test suite
is not completely independent of what is installed ?

You can't really avoid it unless you compile without embedded rpath.

But shouldn't the minor-version bump between 7.3 and 7.4 libpq.so have
prevented the dynamic linker from accepting the 7.3 libpq.so as the one
to use? I thought the rule was "same major version as requested, minor
version >= requested".

regards, tom lane

[snip]

The problem was that the new psql was linking to an older version of
libpq.so (one that doesn't export get_progname()). As best I can tell
that would have had to be a 7.3 libpq.so, which means there is something
wrong here because the 7.3 libpq should have had a different minor
number that would prevent the dynamic linker from accepting it as a
substitute. What platform are you using?

regards, tom lane

OS: linux RedHat 9 (with possible updates from their site)
Kernel: 2.4.20-20.9
The installed postgres version: 7.3.2 (compiled from CVS sources);
The tested postgres version: 7.4.2 (compiled from CVS sources)

HTH,
Csaba.

Tom Lane wrote:

But shouldn't the minor-version bump between 7.3 and 7.4 libpq.so
have prevented the dynamic linker from accepting the 7.3 libpq.so as
the one to use? I thought the rule was "same major version as
requested, minor version >= requested".

Maybe, but the directory search order comes first. If a compatible
library is found, it is used, no matter whether "better" compatible
library files are available in other directories that are searched
later.

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

But shouldn't the minor-version bump between 7.3 and 7.4 libpq.so
have prevented the dynamic linker from accepting the 7.3 libpq.so as
the one to use? I thought the rule was "same major version as
requested, minor version >= requested".

Maybe, but the directory search order comes first. If a compatible
library is found, it is used, no matter whether "better" compatible
library files are available in other directories that are searched
later.

But it shouldn't have been considered compatible, period. I am
wondering if the psql executable was misbuilt to specify that it wanted
libpq >= 3.0, rather than >= 3.1 as it should have said.

regards, tom lane

On Thu, 2004-03-11 at 17:26, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

But shouldn't the minor-version bump between 7.3 and 7.4 libpq.so
have prevented the dynamic linker from accepting the 7.3 libpq.so as
the one to use? I thought the rule was "same major version as
requested, minor version >= requested".

Maybe, but the directory search order comes first. If a compatible
library is found, it is used, no matter whether "better" compatible
library files are available in other directories that are searched
later.

But it shouldn't have been considered compatible, period. I am
wondering if the psql executable was misbuilt to specify that it wanted
libpq >= 3.0, rather than >= 3.1 as it should have said.

regards, tom lane

I'm ignorant about dynamic library loading... I found the "readelf"
program would tell some info about compiled binaries, here's what I've
got:

cnagy$/opt/pgsql/lib> readelf -d libpq.so

Dynamic segment at offset 0x106f4 contains 25 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libcrypt.so.1]
0x00000001 (NEEDED) Shared library:
[libresolv.so.2]
0x00000001 (NEEDED) Shared library: [libnsl.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000e (SONAME) Library soname: [libpq.so.3]
0x0000000f (RPATH) Library rpath: [/opt/pgsql/lib]
0x0000000c (INIT) 0x317c
0x0000000d (FINI) 0xd4d0
0x00000004 (HASH) 0x94
0x00000005 (STRTAB) 0x1800
0x00000006 (SYMTAB) 0x7c0
0x0000000a (STRSZ) 2764 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x107f0
0x00000002 (PLTRELSZ) 1160 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x2cf4
0x00000011 (REL) 0x2554
0x00000012 (RELSZ) 1952 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x24d4
0x6fffffff (VERNEEDNUM) 2
0x6ffffff0 (VERSYM) 0x22cc
0x6ffffffa (RELCOUNT) 231
0x00000000 (NULL) 0x0

cnagy$/home/cnagy/dev/domeus/pgsql/src/bin/scripts> readelf -d createdb

Dynamic segment at offset 0x46d8 contains 30 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libpq.so.3]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library:
[libreadline.so.4]
0x00000001 (NEEDED) Shared library:
[libtermcap.so.2]
0x00000001 (NEEDED) Shared library: [libcrypt.so.1]
0x00000001 (NEEDED) Shared library:
[libresolv.so.2]
0x00000001 (NEEDED) Shared library: [libnsl.so.1]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath:
[/opt/pgsql-7.4/lib]
0x0000000c (INIT) 0x8048bac
0x0000000d (FINI) 0x804a968
0x00000004 (HASH) 0x8048128
0x00000005 (STRTAB) 0x8048674
0x00000006 (SYMTAB) 0x80482b4
0x0000000a (STRSZ) 768 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x804d804
0x00000002 (PLTRELSZ) 352 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x8048a4c
0x00000011 (REL) 0x8048a1c
0x00000012 (RELSZ) 48 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x80489ec
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x8048974
0x00000000 (NULL) 0x0

Looks like there's no minor version info at all in the binaries, I would
say...

Cheers,
Csaba.

Csaba Nagy <nagy@ecircle-ag.com> writes:

Looks like there's no minor version info at all in the binaries, I would
say...

On investigation, I can't find any sign that my Linux box does anything
with library minor version numbers either. That seems to mean that we
should be bumping the major version for every release (unless we made
no externally visible changes at all, not even upward-compatible
additions). Ugh.

regards, tom lane

Hi all,

Necessary to inside insert archives (jpg, doc) of the bd using delphi +
DBExpress
How to make this?
Exists an example?

regards, fern

Tom Lane wrote:

On investigation, I can't find any sign that my Linux box does
anything with library minor version numbers either. That seems to
mean that we should be bumping the major version for every release
(unless we made no externally visible changes at all, not even
upward-compatible additions). Ugh.

No we don't, because we set the rpath and our installation routines take
care that in the target directory the libfoo.so.X is in fact the latest
library. The only problem that make check has is that it bypasses the
prober installation routines, in a sense.

Peter Eisentraut <peter_e@gmx.net> writes:

No we don't, because we set the rpath and our installation routines take
care that in the target directory the libfoo.so.X is in fact the latest
library. The only problem that make check has is that it bypasses the
prober installation routines, in a sense.

Okay, so the point is that the embedded rpath trumps the LD_LIBRARY_PATH
that pg_regress.sh tries to supply. Which in fact is the whole point of
rpath (not to be environment-sensitive) so I guess we can't complain.

Seems like the only real solution would be for "make check" to relink
psql to have an rpath pointing at the temp installation. I wonder if
that's practical at all?

regards, tom lane

"TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:

TL> On investigation, I can't find any sign that my Linux box does anything
TL> with library minor version numbers either. That seems to mean that we
TL> should be bumping the major version for every release (unless we made
TL> no externally visible changes at all, not even upward-compatible
TL> additions). Ugh.

I think you should bump the revision at least on major version
upgrade. See in FreeBSD:

[fp01]% psql --version
psql (PostgreSQL) 7.3.4
contains support for command-line editing
[fp01]% ls -l /usr/local/lib/libpq.*
-rw-r--r-- 1 root wheel 99372 Sep 12 2003 /usr/local/lib/libpq.a
lrwxr-xr-x 1 root wheel 10 Sep 12 2003 /usr/local/lib/libpq.so@ -> libpq.so.3
-rwxr-xr-x 1 root wheel 79168 Sep 12 2003 /usr/local/lib/libpq.so.3*

[yertle]% psql --version
psql (PostgreSQL) 7.4
contains support for command-line editing
[yertle]% ls -l /usr/local/pgsql/lib/libpq.*
-rw-r--r-- 1 root postgres 123222 Nov 26 13:41 /usr/local/pgsql/lib/libpq.a
lrwxr-xr-x 1 root postgres 10 Nov 26 13:41 /usr/local/pgsql/lib/libpq.so@ -> libpq.so.3
-rwxr-xr-x 1 root postgres 98240 Nov 26 13:41 /usr/local/pgsql/lib/libpq.so.3*

In PG 7.2, it was libpq.so.2

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/