Thread: "make check" fails for 7.4.2 checked out from CVS
Hi all, I have checked out the REL7_4_2 version from the public CVS repository, and running "make check" fails with: [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 Running just "make" finishes OK, everything compiles. I've used the following configure command: ./configure --enable-multibyte --enable-locale --prefix=/opt/pgsql I have a 7.3 version installed, but I've made sure the path does not point to it. There's no accessible createdb on the path. The OS I'm using: a plain RedHat 9 installation with 2.4.20-20.9 kernel. Do you have any hints/ideas about what's happening ? Thanks, Csaba.
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. On Thu, 2004-03-11 at 11:45, Csaba Nagy wrote: > Hi all, > > I have checked out the REL7_4_2 version from the public CVS repository, > and running "make check" fails with: > > [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 > > > Running just "make" finishes OK, everything compiles. > > I've used the following configure command: > > ./configure --enable-multibyte --enable-locale --prefix=/opt/pgsql > > I have a 7.3 version installed, but I've made sure the path does not > point to it. There's no accessible createdb on the path. > > The OS I'm using: a plain RedHat 9 installation with 2.4.20-20.9 kernel. > > Do you have any hints/ideas about what's happening ? > > Thanks, > Csaba. > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
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.
Re: "make check" fails for 7.4.2 checked out from CVS
From
"V i s h a l Kashyap @ [Sai Hertz And Control Systems]"
Date:
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---------------------
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. On Thu, 2004-03-11 at 14:24, Peter Eisentraut wrote: > 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. > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
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
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
[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.
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/