Call for platforms

NetBSD-1.5/i386 one spurious floating point test failure
(mail sent to postgresql-bugs with details)
NetBSD_1.5/alpha all tests passed
NetBSD-1.4.2/i386 four tests fail

Thanks! I'm not too worried about 1.4.2, but be sure to let us know what
the problem was; it may help out someone else...

- Thomas

Thanks! I'm not too worried about 1.4.2, but be sure to let us know what
the problem was; it may help out someone else...

NetBSD-1.4.2/i386 passes all tests with 7.1RC3.

My previous test failure on this platform was due to the timezone
information on the test system not being standard; once that was
corrected all tests pass.

It is still necessary to add -ltermcap after -ledit in
src/Makefile.global to have functional history editing in psql.

Regards,

Giles

Giles Lean <giles@nemeton.com.au> writes:

It is still necessary to add -ltermcap after -ledit in
src/Makefile.global to have functional history editing in psql.

This is a weakness in the configure script: it goes through a loop
where it tries to link a program that calls readline() with, in order,
"-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses",
"-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit
-lncurses" and "-ledit -lcurses". The first link that succeeds wil
determine which libraries are used. However, on some platforms with
dynamic libraries, the link will succeed as soon as readline() is
present -- but the shared library that contains it doesn't contain a
complete specification of all other libraries it needs at run-time
(the executable is expected to hold this information), and the program
fails at run-time even though it linked without any error message.

I don't know how the situation could best be improved, though...

-tih
--
The basic difference is this: hackers build things, crackers break them.

Tom Ivar Helbekkmo writes:

Giles Lean <giles@nemeton.com.au> writes:

It is still necessary to add -ltermcap after -ledit in
src/Makefile.global to have functional history editing in psql.

This is a weakness in the configure script: it goes through a loop
where it tries to link a program that calls readline() with, in order,
"-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses",
"-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit
-lncurses" and "-ledit -lcurses". The first link that succeeds wil
determine which libraries are used. However, on some platforms with
dynamic libraries, the link will succeed as soon as readline() is
present -- but the shared library that contains it doesn't contain a
complete specification of all other libraries it needs at run-time
(the executable is expected to hold this information), and the program
fails at run-time even though it linked without any error message.

On such a platform it would hardly be possible to detect anything with any
reliably. A linker that links a program "succesfully" while the program
really needs more libraries to be runnable isn't very useful.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

On such a platform it would hardly be possible to detect anything with any
reliably. A linker that links a program "succesfully" while the program
really needs more libraries to be runnable isn't very useful.

You're right, of course -- it's a bug in the linkage loader on the
platform in question. NetBSD/vax has it:

$ uname -a
NetBSD varg.i.eunet.no 1.5T NetBSD 1.5T (VARG) #4: Thu Apr 5 23:38:04 CEST 2001
root@varg.i.eunet.no:/usr/src/sys/arch/vax/compile/VARG vax
$ cat > foo.c
int main (int argc, char **argv) { readline(); }
$ cc -o foo foo.c
/tmp/ccFTO4Mu.o: Undefined symbol `_readline'referenced from text segment
collect2: ld returned 1 exit status
$ cc -o foo foo.c -ledit
$ echo $?
0
$ ./foo
/usr/libexec/ld.so: Undefined symbol "_tputs"in foo:/usr/lib/libedit.so.2.5
$ echo $?
1
$ ldd foo
foo:
-ledit.2 => /usr/lib/libedit.so.2.5 (0x181b000)
-lc.12 => /usr/lib/libc.so.12.74 (0x182d000)
$

-tih
--
The basic difference is this: hackers build things, crackers break them.