Thread: CVS Head psql bug?
Hi, I'm getting following error while envoking psql: $ psql psql: symbol lookup error: /usr/lib/libreadline.so.5: undefined symbol: BC This is Linux glibc 2.3.4 and readline 5.1. -- Tatsuo Ishii SRA OSS, Inc. Japan
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.oinput.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.o large_obj.o print.o describe.o psqlscan.o tab-complete.ombprint.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.oinput.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.o large_obj.o print.o describe.o psqlscan.o tab-complete.ombprint.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&br=HEAD -- Guillaume