psql: relocation error: psql: undefined symbol: PQgetssl

[Phil Campaigne]

Hi All,
I just installed postgresql 7.3.4 as an upgrade to 7.3.2 and all went
well untill I tried to log into a database that I successfully created.
Here are the steps in question:

bash-2.05b$ psql -h localhost -U postgres hardwoodthunder
Welcome to psql 7.3.2, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

psql: relocation error: psql: undefined symbol: PQgetssl
bash-2.05b$ \q
bash: q: command not found
bash-2.05b$

Does anyone have any suggestions?
thanks,
Phil
---------------------------(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

[Reece Hart]

On Thu, 2004-01-22 at 16:13, Phil Campaigne wrote:

psql: relocation error: psql: undefined symbol: PQgetssl

Phil-

I vaguely remember seeing a similar message when I inadvertently
mismatched versions of psql and libpq. I think that the problem was psql
resolving to the wrong libpq, but this is an old memory.

Some suggestions:
1) ldd psql
This will tell you which libraries are being dynamically linked. Make
sure you think this what you expect.

2) check/unset your LD_LIBRARY_PATH variable.

3) I'm guessing you're on a linux box (guess per mail header), I also
guess you might have an RPM-based system. If so, I'd further guess that
you've recompiled postgresql AND have an rpm-installed version. rpm -e
postgresql will remove the rpm version (can't remember if postgresql
rpms are divided into subpackages... you might actually need
postgresql-libs and postgresql-clients or some such names).

-Reece
--
Reece Hart, http://www.in-machina.com/~reece/, GPG:0x25EC91A0

[Tom Lane]

Reece Hart <re***@in-machina.com> writes:

On Thu, 2004-01-22 at 16:13, Phil Campaigne wrote:

psql: relocation error: psql: undefined symbol: PQgetssl

I vaguely remember seeing a similar message when I inadvertently
mismatched versions of psql and libpq. I think that the problem was psql
resolving to the wrong libpq, but this is an old memory.

This undoubtedly indicates that you have an SSL-enabled psql that is
trying to use a non-SSL-enabled libpq.so. So (a) you were not
consistent about your configure options between 7.3.2 and 7.3.4
--- you might want to look and see if there were any other unintentional
changes; and (b) your ldconfig or LD_LIBRARY_PATH setup is finding the
"wrong" version of libpq.so. Reece's suggestion to use ldd will help
you figure out what's up with (b).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[scott.marlowe]

On Thu, 22 Jan 2004, Phil Campaigne wrote:

Hi All,
I just installed postgresql 7.3.4 as an upgrade to 7.3.2 and all went
well untill I tried to log into a database that I successfully created.
Here are the steps in question:

bash-2.05b$ psql -h localhost -U postgres hardwoodthunder
Welcome to psql 7.3.2, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

Notice that after upgrading to 7.3.4, you are using the psql that was
installed with 7.3.2...


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Reece Hart]

On Thu, 2004-01-22 at 18:00, Phil Campaigne wrote:

Thanks for your reply. My system has Red Hat 8.0 with postgresql
installed from it as rpm. Then I tried to rpm -e and went to the
postgresql-7.3.4.tar.gz distribution of source because the rpm wasn't
yet available.

I don't see the LD_LIBRARY_PATH listed using the "env" command, and I
can't get the command "ldd psql" to be recognized.
:+( Phil

LD_LIBRARY_PATH is often not set except for users with specific needs.
Having it set might lead to your symptoms, but having it unset is almost
certainly fine.

That's ldd (not lld) and you certainly have it... it's part of
glibc-common which in turn is required (in the rpm sense) by glibc.
Example:

whoville$ ldd `type -p psql`
libpq.so.3 => /apps/compbio/i686-linux-2.4/opt/postgresql-7.4/lib/libpq.so.3 (0x40017000)
libpam.so.0 => /lib/libpam.so.0 (0x40045000)
libssl.so.2 => /lib/libssl.so.2 (0x4004d000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x4007c000)
(and so on)
Tip: pg_config --configure will tell you how the current installation
was configured. I recompile roughly like this:

$ cd postgresql-7.4.1
$ pg_config --configure
'--prefix=/apps/compbio/i686-linux-2.4/opt/postgresql-7.4'
'--with-perl' '--with-python' '--with-tcl' '--with-CXX'
'--with-openssl' '--with-pam' '--with-krb5=/usr/kerberos'
$ ./configure <copy/paste above line, changing --prefix directory>
$ make
$ make install

The --prefix bit is there because I like to keep several versions
around.

-Reece

--
Reece Hart, http://www.in-machina.com/~reece/, GPG:0x25EC91A0 0xD178AAF9