Обсуждение: pgtcl installation problem
I have installed postgresql 8.2.0 and pgtclng 1.5.3 but the
installation of pgtclng 1.5.3 is faulty. I hope someone can tell me
what I'm doing wrong.
I try to run this script (named see):
#!/usr/local/bin/tclsh package require Pgtcl set fd [pg_connect -conninfo "host = localhost dbname =
mtw"]
and get this response:
couldn't load file "/usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so":
/usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so: undefined symbol:
lo_export while executing
"load /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so pgtcl" ("package ifneeded" script) invoked from within
"package require Pgtcl" (file "./see" line 2)
With nm /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so I see
U lo_close U lo_creat U lo_export U lo_import U lo_lseek U lo_open
U lo_read U lo_tell U lo_unlink U lo_write U memcpy@@GLIBC_2.0
but
00005740 T Pg_lo_close
00004f80 T Pg_lo_creat
00004a70 T Pg_lo_export
00004bd0 T Pg_lo_import
000051c0 T Pg_lo_lseek
00005860 T Pg_lo_open
00005560 T Pg_lo_read
00004e40 T Pg_lo_tell
00004d20 T Pg_lo_unlink
000053e0 T Pg_lo_write
This is on Linux, fairly up-to-date.
Hope someone can help. I have been using an earlier version of pgtcl
with postgresql 8.1 but now I'm lost and stuck.
Dunno why I see U memcpy@@GLIBC_2.0
because I have /lib/libc-2.4.so. But I have very little understanding
this stuff (the linker).
--Mike Talbot-Wilson
Michael Talbot-Wilson <mtw@view.net.au> writes:
> With nm /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so I see
> U lo_close
> U lo_creat
> U lo_export
> U lo_import
> U lo_lseek
> U lo_open
> U lo_read
> U lo_tell
> U lo_unlink
> U lo_write
It should be getting those from libpq --- probably its reference to
libpq.so is borked somehow. What does ldd tell you?
regards, tom lane
On Sat, Dec 23, 2006 at 08:52:15PM +1030, Michael Talbot-Wilson wrote:
> I have installed postgresql 8.2.0 and pgtclng 1.5.3 but the
> installation of pgtclng 1.5.3 is faulty. I hope someone can tell me
> what I'm doing wrong.
>...
> couldn't load file "/usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so":
> /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so: undefined symbol:
> lo_export
> while executing
> "load /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so pgtcl"
> ("package ifneeded" script)
> invoked from within
> "package require Pgtcl"
> (file "./see" line 2)
Wow. I have no idea why you would get undefined on (just) the lo_* calls.
As Tom pointed out, those are in the PostgreSQL libpq library, whereas the
Pg_lo_* functions you show as "T" are internal to Pgtclng.
> With nm /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so I see
>
> U lo_close
> ...
This is normal. Those symbols are in libpq and nm will report them as
undefined. You should also see "U" for PQclear, PQexec, and lots more
beginning with "PQ".
First thing to do is what Tom said: ldd /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so
Let's see if it can find libpq. (Yes, if not it should have said that when
you did "package require", but who knows.)
I have noticed that the pgtclng build includes the path to libpq (rpath),
where I think the original Pgtcl does not. In my testing, it meant that
original Pgtcl won't run without the PostgreSQL library directory in
LD_LIBRARY_PATH or /etc/ld.so.conf, and my pgtcl-ng won't run if you build
it on one system and use it elsewhere with a different PostgreSQL library
path. I think there are valid points on both sides, but I'm no expert.
On Sat, 23 Dec 2006, Tom Lane wrote: > Michael Talbot-Wilson <mtw@view.net.au> writes: >> With nm /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so I see > >> U lo_close >> ... > > It should be getting those from libpq --- probably its reference to > libpq.so is borked somehow. What does ldd tell you? Thanks. This hint put me on the right track. It told me: 1 mtw@peregrine[19:15:23]:/usr/local/lib/pgtcl1.5.3$ ldd libpgtcl1.5.3.so linux-gate.so.1 => (0xffffe000) libdl.so.2 => /lib/libdl.so.2 (0xb7fe9000) libm.so.6 => /lib/libm.so.6 (0xb7fc4000) libc.so.6 => /lib/libc.so.6(0xb7ea5000) /lib/ld-linux.so.2 (0x80000000) 1 mtw@peregrine[19:15:35]:/usr/local/lib/pgtcl1.5.3$ But now it says: 1 mtw@peregrine[20:08:03]:/usr/local/lib/pgtcl1.5.3$ ldd libpgtcl1.5.3.so linux-gate.so.1 => (0xffffe000) libpq.so.5 => /usr/local/libexec/pgsql/lib/libpq.so.5 (0xb7ef5000) libdl.so.2 => /lib/libdl.so.2 (0xb7ef1000) libm.so.6 => /lib/libm.so.6 (0xb7ecc000) libc.so.6 => /lib/libc.so.6 (0xb7dad000) libssl.so.0 => /usr/lib/libssl.so.0(0xb7d7b000) libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0xb7c7d000) libcrypt.so.1 => /lib/libcrypt.so.1(0xb7c4f000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7c3c000) /lib/ld-linux.so.2 (0x80000000) 1 mtw@peregrine[20:08:16]:/usr/local/lib/pgtcl1.5.3$ --Mike Talbot-Wilson
On Sat, 23 Dec 2006, L Bayuk wrote: > ... > I have noticed that the pgtclng build includes the path to libpq (rpath), > where I think the original Pgtcl does not. In my testing, it meant that > original Pgtcl won't run without the PostgreSQL library directory in > LD_LIBRARY_PATH or /etc/ld.so.conf, and my pgtcl-ng won't run if you build > ... I had it in /etc/ld.so.conf, but I guess that only works at run time. But I had a mess generally, as my response to Tom Lane indicates. Apart from removing some obsolete PATH directories revealed by config.log, all I did was add --with-postgres-include and --with-postgres-lib options and paths to configure. Strangely (to me), that also brought the crypt and ssh libraries to light. I was confused because ./configure with no options produced no complaints, or I didn't notice any. Thanks for your help. --Mike Talbot-Wilson
I ran into the same problem. When I manually specified libdir,
with-postgres-include, and with-postgres-lib for the configure script,
it worked. Note that I also had to untar the source code again for the
second install to work (no make mrproper?).
For my system, the following values pulled from the INSTALL file
worked:
./configure --libdir=/usr/lib/tcl8.4
--with-postgres-include=$(pg_config --includedir)
--with-postgres-lib=$(pg_config --libdir)
It would be nice if the install script checks that the library loads
successfully before installing.
Adam
Michael Talbot-Wilson wrote:
> I have installed postgresql 8.2.0 and pgtclng 1.5.3 but the
> installation of pgtclng 1.5.3 is faulty. I hope someone can tell me
> what I'm doing wrong.
>
> I try to run this script (named see):
>
> #!/usr/local/bin/tclsh
> package require Pgtcl
> set fd [pg_connect -conninfo "host = localhost dbname = mtw"]
>
> and get this response:
>
> couldn't load file "/usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so":
> /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so: undefined symbol:
> lo_export
> while executing
> "load /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so pgtcl"
> ("package ifneeded" script)
> invoked from within
> "package require Pgtcl"
> (file "./see" line 2)
>
> With nm /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so I see
>
> U lo_close
> U lo_creat
> U lo_export
> U lo_import
> U lo_lseek
> U lo_open
> U lo_read
> U lo_tell
> U lo_unlink
> U lo_write
> U memcpy@@GLIBC_2.0
>
> but
>
> 00005740 T Pg_lo_close
> 00004f80 T Pg_lo_creat
> 00004a70 T Pg_lo_export
> 00004bd0 T Pg_lo_import
> 000051c0 T Pg_lo_lseek
> 00005860 T Pg_lo_open
> 00005560 T Pg_lo_read
> 00004e40 T Pg_lo_tell
> 00004d20 T Pg_lo_unlink
> 000053e0 T Pg_lo_write
>
> This is on Linux, fairly up-to-date.
>
> Hope someone can help. I have been using an earlier version of pgtcl
> with postgresql 8.1 but now I'm lost and stuck.
>
> Dunno why I see
> U memcpy@@GLIBC_2.0
> because I have /lib/libc-2.4.so. But I have very little understanding
> this stuff (the linker).
>
> --Mike Talbot-Wilson
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
On Sat, Dec 23, 2006 at 08:15:08AM -0800, Deadwood wrote: > Note that I also had to untar the source code again for the > second install to work (no make mrproper?). Use "make distclean", which I think is the GNU standard for that. (Don't know where the Linux folks got "mrproper" from.) > For my system, the following values pulled from the INSTALL file > worked: > ./configure --libdir=/usr/lib/tcl8.4 > --with-postgres-include=$(pg_config --includedir) > --with-postgres-lib=$(pg_config --libdir) Yes, that is what works for me. But I agree that the fact that "configure" alone seems to work, and then make fails when it can't find the headers, is a bad thing. I think the "other" Pgtcl project has it default to using pg_config to get the values, which is much better. Assuming pg_config is in your PATH. I have a new release of pgtclng almost ready, with event-driven asynchronous queries, and I will see if I can improve the default configure behavior. > It would be nice if the install script checks that the library loads > successfully before installing. Yes it would be very nice. As it stands now, it will happily make the library even with missing dependencies. But I don't know how to fix that. Know of anything autoconf-based that detects this situation?