Hi,
the following configure/make batch with postgresql-7.4beta4
results with the error below.
That is to say, make does work fine,
but make check results in an error. Oviously the target-directory
given with prefix is already used in some way with make check
(when make install is not yet run). This error did not occur with 7.3
versions, where the make test seemed to restrict itself to the source
directory and did not touch the target directory given by prefix.
The OS is Suse 8.2 with bison updated to 1.85 as required because of a
resp. warning from configure.

SourceDir="/usr/local/src/postgresql-7.4beta4"
TargetDir="/opt/doka/"
PORTNR=5432
export LC_LANG=de_DE@euro
export LC_COLLATE=de_DE
datum=`date +%d%b%Y_%H%M`
make clean
../configure --prefix=$TargetDir/pgsql \
--enable-nls='de' \
--with-pgport=$PORTNR \
--with-tcl \
--with-odbc \
--with-perl \
--with-openssl \
--with-python
make check

This did result in the following ...
============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 65432 with pid 48
============== creating database "regression" ==============
/usr/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
relocation error:
/us/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
undefined symbol: get_proname
pg_regress: createdb failed
make[2]: *** [check] Fehler 2
make[2]: Leaving directory
`/usr/local/src/postgresql-7.4beta4/src/test/regress'
make[1]: *** [check] Fehler 2
make[1]: Leaving directory `/usr/local/src/postgresql-7.4beta4/src/test'
make: *** [check] Fehler 2
postgres@zs:/usr/local/src/postgresql-7.4beta4>

Regards
Christoph Becker



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Christoph Becker <CGBecker (AT) gmx (DOT) de> writes:
Hm. I have a feeling your temp installation is somehow linking to an
old version of libpq, because that's the most common reason for
link-time failures in "make check". But I don't understand the
reference to 'get_proname'. There is no occurrence of that string in
either current sources or any recent PG release.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

tgl (AT) sss (DOT) pgh.pa.us wrote:
I got the same error with beta1, but the symbol was "get_progname"
not "get_proname". Perhaps the above is a typo. I also thought the thing
was somehow using my current 7.3 install when linking the 7.4 tests.
Didn't happen with beta2, but could be because then I had beta1 installed.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

ljb <ljb220 (AT) mindspring (DOT) com> writes:
"get_progname" would make sense, because that's a symbol defined in
libpgport in 7.4 that did not exist in 7.3. So if the dynamic linker
was finding your 7.3 PG library directory instead of 7.4, you'd likely
get this error.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

tgl (AT) sss (DOT) pgh.pa.us wrote:
Confirmed. Perhaps this should be looked into. On my system, "make check"
works fine if there is no existing PostgreSQL installation. But if there
is, we seem to prefer the existing installation's libraries over what
pg_regress sets LD_LIBRARY_PATH to (the newly built software). This means
that "make check" will either fail in createdb (if the existing install is
7.3, for example) or work but actually be testing the newly built programs
using the existing version's run-time libpq library.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

ljb <ljb220 (AT) mindspring (DOT) com> writes:
Yeah, we have seen this before on various platforms. On some,
LD_LIBRARY_PATH isn't actually anything the dynamic linker pays
attention to, and on others, it is trumped by the installation rpath
built into the executables. Not putting an rpath into the executables
would make life better for "make check" at the cost of making the
executables much more fragile in actual use. I don't see a good
solution :-( but if you do, step right up to the plate ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

tgl (AT) sss (DOT) pgh.pa.us wrote:
Well, I'm not going to be the one who suggests that adding:
export LD_PRELOAD=$libdir/libpq.so
to pg_regress.sh before the initdb command will fix it (on Linux).

Because the more I think about it, the less I like the idea of "make check"
as a way to validate PostgreSQL. Not only because it looks like some of us
may have actually been testing a hybrid "new programs/old libraries"
combination, but because "make check" uses a temporary installation. For
acceptance testing, I want to know that it was built and installed
properly, so I'll have to use "make installcheck" after installation. (Say,
why isn't this listed in INSTALL anymore?)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org