Tab-completion error...?
I'm having a problem with v14.1 on my Raspberry Pi 4[8Gb]
After a clean download and compile, when using psql, using tab completion
psql -U postgres
postgres=# \i my_databases\tpsql: symbol lookup error: psql: undefined
symbol: PQmblenBounded
On 12/22/21 1:15 PM, Theodore M Rolle, Jr. wrote:
I'm having a problem with v14.1 on my Raspberry Pi 4[8Gb]
After a clean download and compile, when using psql, using tab completion
psql -U postgres
postgres=# \i my_databases\tpsql: symbol lookup error: psql: undefined
symbol: PQmblenBounded
Not sure what you are showing.
My best guess is you:
1) Typed \i my_databases
2) Hit the Tab key to complete the file listing.
Is this correct?
If not write out what you did.
I'm going to say it is an issue with whatever is being used to supply
readline on the RPI.
Do you know what that is?
Or can you look at config.log where you ran ./configure to see what it
found or did not finc?
--
Adrian Klaver
adrian.klaver@aklaver.com
On Wed, Dec 22, 2021 at 10:16 PM Theodore M Rolle, Jr. <stercor@gmail.com>
wrote:
I'm having a problem with v14.1 on my Raspberry Pi 4[8Gb]
After a clean download and compile, when using psql, using tab completion
psql -U postgres
postgres=# \i my_databases\tpsql: symbol lookup error: psql: undefined
symbol: PQmblenBounded
This looks like your libpq is out of sync with your psql. That is, likely
your psql is 14.1, but libpq is an older version. You may have more than
one version of libpq on the system. For example, you have your own compiled
version of psql, but it's using a system-default version of libpq.so which
is from an older version.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
On 12/22/21 2:14 PM, Theodore M Rolle, Jr. wrote:
Please reply to list also.
Ccing list.
From below, what did pacman -Syyuu do?
You are correct in guessing what I did...
config.log:
a bunch of
#define HAVE_LIBREADLINE 1
then
configure:13450: checking readline/readline.h usability
configure:13450: gcc -c -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
-Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -O2 -I/home/ted/hercules-helper/rexx/include
-D_GNU_SOURCE conftest.c >&5
configure:13450: $? = 0configure:13450: result: yes
configure:13450: checking readline/readline.h presence
configure:13450: gcc -E -I/home/ted/hercules-helper/rexx/include
-D_GNU_SOURCE conftest.c
configure:13450: $? = 0
configure:13450: result: yes
configure:13450: checking for readline/readline.h
configure:13450: result: yes
configure:13480: checking readline/history.h usability
configure:13480: gcc -c -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -O2
-I/home/ted/hercules-helper/rexx/include -D_GNU_SOURCE conftest.c >&5
configure:13480: $? = 0
configure:13480: result: yes
configure:13480: checking readline/history.h presence
configure:13480: gcc -E -I/home/ted/hercules-helper/rexx/include
-D_GNU_SOURCE conftest.c
configure:13480: $? = 0
configure:13480: result: yes
configure:13480: checking for readline/history.h
configure:13480: result: yes
configure:13602: checking zlib.h usability
configure:13602: gcc -c -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -O2
-I/home/ted/hercules-helper/rexx/include -D_GNU_SOURCE conftest.c >&5
configure:13602: $? = 0It looks good, doesn't it?
N.B. v14.1 is the first version to have this problem. Another thought:
perhaps the pacman -Syyuu update did it.
--
Adrian Klaver
adrian.klaver@aklaver.com
Import Notes
Reply to msg id not found: CAPDmd-BqcfGAqc5sW8L05jn1C6LtZ=ctQspNv5wjmR0LeqmoDQ@mail.gmail.com
I don't use pacman for PostgreSQL.
I compile from source.
Seems as though this error shouldn't happen.
On Wed, Dec 22, 2021 at 5:24 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
On 12/22/21 2:14 PM, Theodore M Rolle, Jr. wrote:
Please reply to list also.
Ccing list.From below, what did pacman -Syyuu do?
You are correct in guessing what I did...
config.log:
a bunch of
#define HAVE_LIBREADLINE 1
then
configure:13450: checking readline/readline.h usability
configure:13450: gcc -c -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
-Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -O2 -I/home/ted/hercules-helper/rexx/include
-D_GNU_SOURCE conftest.c >&5
configure:13450: $? = 0configure:13450: result: yes
configure:13450: checking readline/readline.h presence
configure:13450: gcc -E -I/home/ted/hercules-helper/rexx/include
-D_GNU_SOURCE conftest.c
configure:13450: $? = 0
configure:13450: result: yes
configure:13450: checking for readline/readline.h
configure:13450: result: yes
configure:13480: checking readline/history.h usability
configure:13480: gcc -c -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -O2
-I/home/ted/hercules-helper/rexx/include -D_GNU_SOURCE conftest.c
&5
configure:13480: $? = 0
configure:13480: result: yes
configure:13480: checking readline/history.h presence
configure:13480: gcc -E -I/home/ted/hercules-helper/rexx/include
-D_GNU_SOURCE conftest.c
configure:13480: $? = 0
configure:13480: result: yes
configure:13480: checking for readline/history.h
configure:13480: result: yes
configure:13602: checking zlib.h usability
configure:13602: gcc -c -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -O2
-I/home/ted/hercules-helper/rexx/include -D_GNU_SOURCE conftest.c
&5
configure:13602: $? = 0It looks good, doesn't it?
N.B. v14.1 is the first version to have this problem. Another thought:
perhaps the pacman -Syyuu update did it.--
Adrian Klaver
adrian.klaver@aklaver.com
--
GnuPG/PGP key: 0xDD4276BA
+-----------------------------------------------------------------------------------------------------+
| 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 |
| 58209 74944[59230 78164]06286 20899 86280
+----------------------------------|
| 34825 34211 70679*82148 08651 32823 06647 | May the spirit
|
| 09384 46095 50582 23172 53594 08128 48111 | of π spread
|
| 74502 84102 70193 85211 05559 64462 29489 | around the world.
|
| 54930 38196 44288 10975 66593 34461 28475 | PI VOBISCUM!
|
| 38196 44288 10975 66593 34461 28475 64823
+---------------------------------|
| 37867 83165 27120 19091 45648 56692 34603 48610 45432 6648... |
+----------------------------------------------------------------------------------------------------+
"Theodore M Rolle, Jr." <stercor@gmail.com> writes:
I don't use pacman for PostgreSQL.
I compile from source.
The point is that your from-source build of psql might be linking
to an out-of-date copy of libpq.so provided by the OS. Linux
machines tend to do that (i.e., prefer libraries in /usr/lib[64])
unless you mess with the dynamic loader's configuration.
Try "ldd /path/to/psql" and see what it says about which libpq
is getting used.
regards, tom lane
ldd /usr/local/pgsql/bin/psql
linux-vdso.so.1 (0x0000ffffa2bef000)
libpq.so.5 => /USR/local/lib/libpq.so.5 (0x0000ffffa2aaf000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x0000ffffa2a1d000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x0000ffffa29ed000)
libm.so.6 => /usr/lib/libm.so.6 (0x0000ffffa2941000)
libc.so.6 => /usr/lib/libc.so.6 (0x0000ffffa27cd000)
/lib/ld-linux-aarch64.so.1 => /usr/lib/ld-linux-aarch64.so.1
(0x0000ffffa2bbe000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x0000ffffa2748000
I'm at a loss as to where the /USR came from.
It's not in config.log (compile time)
nor in the psql executable (run time).
On Tue, Jan 4, 2022 at 1:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Theodore M Rolle, Jr." <stercor@gmail.com> writes:
I don't use pacman for PostgreSQL.
I compile from source.The point is that your from-source build of psql might be linking
to an out-of-date copy of libpq.so provided by the OS. Linux
machines tend to do that (i.e., prefer libraries in /usr/lib[64])
unless you mess with the dynamic loader's configuration.Try "ldd /path/to/psql" and see what it says about which libpq
is getting used.regards, tom lane
--
GnuPG/PGP key: 0xDD4276BA
+-----------------------------------------------------------------------------------------------------+
| 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 |
| 58209 74944[59230 78164]06286 20899 86280
+----------------------------------|
| 34825 34211 70679*82148 08651 32823 06647 | May the spirit
|
| 09384 46095 50582 23172 53594 08128 48111 | of π spread
|
| 74502 84102 70193 85211 05559 64462 29489 | around the world.
|
| 54930 38196 44288 10975 66593 34461 28475 | PI VOBISCUM!
|
| 38196 44288 10975 66593 34461 28475 64823
+---------------------------------|
| 37867 83165 27120 19091 45648 56692 34603 48610 45432 6648... |
+----------------------------------------------------------------------------------------------------+
"Theodore M Rolle, Jr." <stercor@gmail.com> writes:
ldd /usr/local/pgsql/bin/psql
linux-vdso.so.1 (0x0000ffffa2bef000)
libpq.so.5 => /USR/local/lib/libpq.so.5 (0x0000ffffa2aaf000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x0000ffffa2a1d000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x0000ffffa29ed000)
libm.so.6 => /usr/lib/libm.so.6 (0x0000ffffa2941000)
libc.so.6 => /usr/lib/libc.so.6 (0x0000ffffa27cd000)
/lib/ld-linux-aarch64.so.1 => /usr/lib/ld-linux-aarch64.so.1
(0x0000ffffa2bbe000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x0000ffffa2748000
Hm, is /USR actually in caps, or did you change that for emphasis?
I'm at a loss as to where the /USR came from.
It's not in config.log (compile time)
nor in the psql executable (run time).
I think it came out of /etc/ld.so.conf.
BTW, by default PG would link psql using an rpath switch pointing at
/usr/local/pgsql/lib, which I assume is where your manual build
put its libpq.so. That's evidently not having success getting that
libpq.so to be used. Did you tell configure to --disable-rpath?
Or maybe move the installation after building it?
regards, tom lane
Fixed.
Turned out to be LD_LIBRARY_PATH had a /USR/local/lib. Changed it to
/usr/local/lib and everything's hunky-dory.
On Tue, Jan 4, 2022 at 6:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Theodore M Rolle, Jr." <stercor@gmail.com> writes:
ldd /usr/local/pgsql/bin/psql
linux-vdso.so.1 (0x0000ffffa2bef000)
libpq.so.5 => /USR/local/lib/libpq.so.5 (0x0000ffffa2aaf000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x0000ffffa2a1d000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x0000ffffa29ed000)
libm.so.6 => /usr/lib/libm.so.6 (0x0000ffffa2941000)
libc.so.6 => /usr/lib/libc.so.6 (0x0000ffffa27cd000)
/lib/ld-linux-aarch64.so.1 => /usr/lib/ld-linux-aarch64.so.1
(0x0000ffffa2bbe000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x0000ffffa2748000Hm, is /USR actually in caps, or did you change that for emphasis?
I'm at a loss as to where the /USR came from.
It's not in config.log (compile time)
nor in the psql executable (run time).I think it came out of /etc/ld.so.conf.
BTW, by default PG would link psql using an rpath switch pointing at
/usr/local/pgsql/lib, which I assume is where your manual build
put its libpq.so. That's evidently not having success getting that
libpq.so to be used. Did you tell configure to --disable-rpath?
Or maybe move the installation after building it?regards, tom lane
--
GnuPG/PGP key: 0xDD4276BA
+-----------------------------------------------------------------------------------------------------+
| 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 |
| 58209 74944[59230 78164]06286 20899 86280
+----------------------------------|
| 34825 34211 70679*82148 08651 32823 06647 | May the spirit
|
| 09384 46095 50582 23172 53594 08128 48111 | of π spread
|
| 74502 84102 70193 85211 05559 64462 29489 | around the world.
|
| 54930 38196 44288 10975 66593 34461 28475 | PI VOBISCUM!
|
| 38196 44288 10975 66593 34461 28475 64823
+---------------------------------|
| 37867 83165 27120 19091 45648 56692 34603 48610 45432 6648... |
+----------------------------------------------------------------------------------------------------+