Hallo all,

after the compilation of 7.4RC2 went fine (it said

All of PostgreSQL successfully made. Ready to install.

;-) I gave an "make check". And this is what I got (after all messages about
what this command prepared, without errors or warnings btw):

/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 5607
============== creating database "regression" ==============
/home/drotschm/.Installation/postgresql-7.4RC2/src/test/regress/./tmp_check/install//PostgreSQL//bin/createdb:
relocation error:
/home/drotschm/.Installation/postgresql-7.4RC2/src/test/regress/./tmp_check/install//PostgreSQL//bin/createdb:
undefined symbol: get_progname
pg_regress: createdb failed
make[2]: *** [check] Error 2
rm regress.o
make[2]: Leaving directory
`/home/drotschm/.Installation/postgresql-7.4RC2/src/test/regress'
make[1]: *** [check] Error 2
make[1]: Leaving directory
`/home/drotschm/.Installation/postgresql-7.4RC2/src/test'
make: *** [check] Error 2

I did this as a normal user, under SuSE Linux 8.2 (i586).

Although a grep told me that symbol "get_progname" is defined in some places
in the src tree, and the "make" went well... Is something wrong inside the
check environment?

Thank you all!
Wolfgang


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Wolfgang Drotschmann <drotschm (AT) fgan (DOT) de> writes:
Hmm. get_progname() should be getting linked into the createdb
executable by way of libpgport.a from the src/port/ directory.
Can you look at the build process in src/port/ and src/bin/scripts/
and try to see what went wrong? The only idea that comes to mind
is that a wrong (old) copy of libpgport got picked up somehow, but
seeing that we don't install it, it's not clear how there could be
an old copy anywhere.

regards, tom lane

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

http://archives.postgresql.org

tgl (AT) sss (DOT) pgh.pa.us wrote:
This sounds like the exact same problem discussed in a thread on this
list on Oct 7. In 'make check', createdb picks up an existing 7.3 libpq
instead of following LD_LIBRARY_PATH. As I posted back then, you might
want to try adding:
export LD_PRELOAD=$libdir/libpq.so
to pg_regress.sh before the initdb command, which might fix it (at least
on Linux).

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Wolfgang Drotschmann <drotschm (AT) fgan (DOT) de> writes:
Well, there's something odd going on, because you're not the first to
report build failures centering on "get_progname". It'd be nice if we
could isolate the difference between the cases that work and the cases
that don't ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Hallo Tom!

Sorry for being late on this...

Short version: Problem solved, reason remains a mystery.

Long version:

Before I wrote the first mail, I checked two times whether I could reproduce
this behaviour. First, I made a "make distclean" before compiling and
checking again. Then, I even removed the whole thing and started from zero.
Both times I got this error message.
In an effort to answer your question above, I started again from scratch on
the same machine... And you guess it - the checks went through.
I don't know what happend that day.

I'm sorry if I raised some dust!

Best regards,
Wolfgang


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match