Re: psql undefined symbol error on Ubuntu

Thanks to all for the responses. Systems Ops has resolved this issue. I am able to successfully connect.


Thanks,
Harsha Hegde
Database Developer,
 Vonage| 23 Main Street | Holmdel, NJ  07733
t: 732-203-7562
e: harshaDOThegdeATvonage.com
location: D1-A161

NOTE: The information contained in this email message is considered confidential and proprietary to the sender and is
intendedsolely for review and use by the named recipient.  Any unauthorized review, use or distribution is strictly
prohibited.If you have received this message in error, please advise the sender by reply email and delete the message. 







-----Original Message-----
From: pgsql-novice-owner@postgresql.org [mailto:pgsql-novice-owner@postgresql.org] On Behalf Of Michael Wood
Sent: Thursday, July 09, 2009 1:10 PM
To: Tom Lane
Cc: pgsql-novice@postgresql.org
Subject: Re: [NOVICE] psql undefined symbol error on Ubuntu

2009/7/9 Tom Lane <tgl@sss.pgh.pa.us>:
> Michael Wood <esiotrot@gmail.com> writes:
>> Google returns many results for the error
>> "/usr/local/lib/libreadline.so.5: undefined symbol: PC".  It is not
>> clear to me why so many people encounter this error, though.
>
> Historically the problem with readline has been that it can function
> with either of two underlying libraries (termcap or ncurses, if memory
> serves) and somebody thought it would be a brilliant idea to postpone
> the decision to runtime.  Which meant that instead of having a package
> manager dependency on one or the other, libreadline packages were
> shipped with no explicit dependency on *either*.  Everything was fine
> if you actually had one of the two installed; if not, not so much.

OK, thanks for the explanation, but it still doesn't really explain why so many people seem to have a broken
libreadlinein /usr/*local*/lib :) 

> Of course this approach is pretty idiotic in the context of modern
> package-manager-based distributions.  Red Hat started forcing a choice
> some years ago.  I'm not sure what Ubuntu does.  I suspect what the OP
> has got is one of these ill-considered packages with no hard
> dependency; but as you say, if it were an official Ubuntu package it
> wouldn't be installing into /usr/local.

Ubuntu appears to depend on libncurses:

$ apt-cache show libreadline5 | grep ^Depends
Depends: readline-common, libc6 (>= 2.6-1), libncurses5 (>= 5.6)

although dpkg supports dependencies which say that one package depends on one of X or Y.

e.g. the dependencies for the gnome-desktop-environment package contains this:
totem-gstreamer (>= 2.22.2) | totem-xine (>= 2.22.2)

There's also another way to do this sort of thing.  Packages can say what they provide, and that can be basically the
nameof the package, or a sort of virtual package.  e.g. all MTAs on Debian and Ubuntu provide "mail-transport-agent": 

$ apt-cache show exim4-daemon-light | grep ^Provides
Provides: exim4-localscanapi-1.0, exim4-localscanapi-1.1, mail-transport-agent

so if another package depends on an MTA, but doesn't care which one, it can just depend on mail-transport-agent.

I seem to remember RPM also supports this, so I don't see why anyone would have decided not to depend on either one,
unlessit was possible to use some of the functionality of libreadline without needing ncurses or termcap. 

> I don't have anything to add to your advice about how to fix it, just
> wanted to shed a bit of light on why readline has got a history of
> this kind of issue.

Thanks :)

--
Michael Wood <esiotrot@gmail.com>

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice