CVS Head psql bug?

Tatsuo Ishii <ishii@postgresql.org> writes:

I'm getting following error while envoking psql:
$ psql
psql: symbol lookup error: /usr/lib/libreadline.so.5: undefined symbol: BC

I believe this is the typical symptom of failing to link to the correct
variant of curses/termcap needed by readline. We haven't changed the
code around that in awhile --- is this a different platform than you've
used before?

regards, tom lane

Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:

I'm getting following error while envoking psql:
$ psql
psql: symbol lookup error: /usr/lib/libreadline.so.5: undefined symbol: BC

I believe this is the typical symptom of failing to link to the correct
variant of curses/termcap needed by readline. We haven't changed the
code around that in awhile --- is this a different platform than you've
used before?

regards, tom lane

Sorry for not follow the thread and posting from different account
than before. I'm currently having trouble with ishii@postgresql.org
account. Marc is kindly working for me and will be fixed soon but...

No the plaform is not changed. I compare the link command for psql 8.3
and current.

8.3:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing command.o common.o help.o input.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.o large_obj.o print.o describe.o psqlscan.o tab-complete.o mbprint.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/port -lpgport -L../../../src/interfaces/libpq -lpq -L../../../src/port -Wl,-rpath,'/usr/local/pgsql/lib' -lpgport -lz -lreadline -lncurses -lcrypt -ldl -lm -o psql

CVS Head:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing command.o common.o help.o input.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.o large_obj.o print.o describe.o psqlscan.o tab-complete.o mbprint.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/port -lpgport -L../../../src/interfaces/libpq -lpq -L../../../src/port -Wl,--as-needed -Wl,-rpath,'/usr/local/src/pgsql/current/lib' -lpgport -lz -lreadline -lncurses -lcrypt -ldl -lm -o psql

So the difference seems:

--as-needed -Wl,

is added to CVS Head. Actually if I remove the option and link psql,
then everything is fine. Any idea?
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Tatsuo Ishii <ishii@sraoss.co.jp> writes:

So the difference seems:
--as-needed -Wl,
is added to CVS Head.

There is code in configure that's supposed to check whether or not that
breaks readline. Would you look at the portion of config.log where it
tests that, and see why it failed to notice a problem?

regards, tom lane

Tatsuo Ishii <ishii@sraoss.co.jp> writes:

So the difference seems:
--as-needed -Wl,
is added to CVS Head.

There is code in configure that's supposed to check whether or not that
breaks readline. Would you look at the portion of config.log where it
tests that, and see why it failed to notice a problem?

It seems configure only checks whether linking was successful. I think
it should check whether ./conftest was successful.

configure:25642: checking if gcc supports -Wl,--as-needed
configure:25674: gcc -o conftest -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -D_GNU_SOURCE -Wl,--as-needed conftest.c -lz -lreadline -lncurses -lcrypt -ldl -lm >&5
configure:25680: $? = 0
configure:25686: result: yes
configure:25765: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing
configure:25767: using CPPFLAGS= -D_GNU_SOURCE
configure:25769: using LDFLAGS= -Wl,--as-needed
configure:25911: creating ./config.status
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Tatsuo Ishii <ishii@sraoss.co.jp> writes:

It seems configure only checks whether linking was successful. I think
it should check whether ./conftest was successful.

Wouldn't work when cross-compiling. What platform is this exactly?

regards, tom lane

Tatsuo Ishii <ishii@sraoss.co.jp> writes:

It seems configure only checks whether linking was successful. I think
it should check whether ./conftest was successful.

Wouldn't work when cross-compiling.

But configure already does this, doesn't it?

configure:24466: checking for working memcmp
configure:24519: gcc -o conftest -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -D_GNU_SOURCE conftest.c -lz -lreadline -lncurses -lcrypt -ldl -lm >&5
configure:24522: $? = 0
configure:24528: ./conftest
configure:24531: $? = 0
configure:24547: result: yes

What platform is this exactly?

The Linux distributions is "Vine Linux", which is a variant of Red Hat
Linux (I think).

$ uname -a
Linux localhost.localdomain 2.6.16-0vl76.33 #1 SMP Fri Feb 15 11:06:36 JST 2008 i686 i686 i386 GNU/Linux
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Tatsuo Ishii <ishii@sraoss.co.jp> writes:

What platform is this exactly?

The Linux distributions is "Vine Linux", which is a variant of Red Hat
Linux (I think).

If it's rpm-based, could we see the RPM package version numbers for
binutils, readline, and ncurses?

regards, tom lane

The Linux distributions is "Vine Linux", which is a variant of Red Hat
Linux (I think).

If it's rpm-based, could we see the RPM package version numbers for
binutils, readline, and ncurses?

Sure.

binutils-2.15.92.0.2-5vl2
readline-5.1-0vl1
readline-devel-5.1-0vl1
ncurses-devel-5.4-0vl3
ncurses-5.4-0vl3
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Tatsuo Ishii <ishii@sraoss.co.jp> writes:

binutils-2.15.92.0.2-5vl2
readline-5.1-0vl1
readline-devel-5.1-0vl1
ncurses-devel-5.4-0vl3
ncurses-5.4-0vl3

Okay, it seems fairly close to RHEL-4 --- at least almost the same
version of binutils, which is probably what counts here. Doesn't
look like there are any RHEL4 or CentOS4 machines in the buildfarm,
which is why we didn't find out about it earlier. I'll go see if
I can reproduce the problem.

regards, tom lane

I wrote:

Okay, it seems fairly close to RHEL-4 --- at least almost the same
version of binutils, which is probably what counts here.

I was able to reproduce the problem on current RHEL-4, and on
examination I don't think it's really ld's fault. The problem is that
libreadline hasn't got a DT_NEEDED entry for libncurses nor libtermcap.
Apparently some benighted fool thought this was a good idea since then
you could use either one :-(. More recent releases have resolved the
issue by replacing both ncurses and termcap with libtinfo, which
thankfully readline now sports a DT_NEEDED dependency for.

Even assuming I could get Red Hat to change the situation in RHEL4
(which would be a long shot), it would take a long time if not forever
for the fix to propagate to derived distros such as Tatsuo-san is using.
So it seems we've got to deal with the situation as it stands.

I studied the ld man page for awhile but couldn't find any fix other
than the one Tatsuo suggests of trying to run the linked test program.
That means we have to guess at what to do in a cross-compilation.
I suppose the safest choice is to not try to use --as-needed when
cross-compiling, but does anyone want to argue for the other choice?
Whichever way we jump, it'd be possible for someone to override
configure's choice by editing the generated Makefile.global, so
my guess is we ought to favor the guaranteed-to-work option.

regards, tom lane

I wrote:

I studied the ld man page for awhile but couldn't find any fix other
than the one Tatsuo suggests of trying to run the linked test program.
That means we have to guess at what to do in a cross-compilation.
I suppose the safest choice is to not try to use --as-needed when
cross-compiling, but does anyone want to argue for the other choice?

I've applied a patch along these lines. I checked it on RHEL-4 and it
seems to work as expected.

regards, tom lane

On Thu, Jun 26, 2008 at 3:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Okay, it seems fairly close to RHEL-4. Doesn't
look like there are any RHEL4 or CentOS4 machines in the buildfarm,
which is why we didn't find out about it earlier.

FYI, I set up a CentOS 4 vserver on one of our buildfarm boxes. It's
called guanaco:
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=guanaco&amp;br=HEAD

--
Guillaume