Thread: Tcl_CreateSlave error (pg 7.1.2, RH 7.2)
Hi all, Yesterday I installed Postgres 7.1.2 on Redhat 7.2. The install appeared to go well, but createlang doesn't work: [joeweb@rex joeweb]$ createlang pltcl joewebtest ERROR: Load of file /usr/local/pgsql-7.1.2/lib/pltcl.so failed: /usr/local/pgsql-7.1.2/lib/pltcl.so: undefined symbol: Tcl_CreateSlave createlang: language installation failed I searched google and the newsgroup archives (the search for the archives for this mailing list seems to be down, so I couldn't search here) and found several people reporting the problem, and one long-ish thread discussing it, but no solutions. Everyone who reported the problem seems to have installed 7.1.3 from an RPM. I installed 7.1.2 from source, so it can't be the RPM's fault. The one person who reported getting this to work said he built 7.1.3 from source and copied over pltcl.so and it worked; since I have already built from source I can't even try that. I had previously installed PG 7.2 in another directory and running on another port; that worked fine. I have also installed 7.1.2 on systems running a heavily upgraded version of RH 6.2, and that worked fine. So it's something about PG 7.1.x plus RH 7.2. Unfortunately I have a client requirement for this version of Postgres so I'm stuck trying to make this work. Ideas, anyone? thanks, janine -- Janine Sisk President/CEO furfly.net, LLC Mont Vernon, NH Phone: 603-672-1122
Janine Sisk <janine@furfly.net> writes:
> Yesterday I installed Postgres 7.1.2 on Redhat 7.2. The install appeared to
> go well, but createlang doesn't work:
> [joeweb@rex joeweb]$ createlang pltcl joewebtest
> ERROR: Load of file /usr/local/pgsql-7.1.2/lib/pltcl.so failed:
> /usr/local/pgsql-7.1.2/lib/pltcl.so: undefined symbol: Tcl_CreateSlave
> createlang: language installation failed
Does the dynamic loader find libtcl.so? Running ldd on pltcl.so might
be enlightening.
FWIW, I see no problem with PG 7.1.3 built from source on stock RH 7.2.
ldd pltcl.so shows
libtcl.so.0 => /usr/lib/libtcl.so.0 (0x40023000)
libdl.so.2 => /lib/libdl.so.2 (0x400a3000)
libm.so.6 => /lib/i686/libm.so.6 (0x400a7000)
libc.so.6 => /lib/i686/libc.so.6 (0x400ca000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
regards, tom lane
Mine is
[joeweb@rex lib]$ ldd pltcl.so
libdl.so.2 => /lib/libdl.so.2 (0x4000f000)
libm.so.6 => /lib/i686/libm.so.6 (0x40013000)
libc.so.6 => /lib/i686/libc.so.6 (0x40036000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
So obviously the problem is that libtcl.so isn't linked in at all. I wonder
how I was able to build it at all?
I do *have* libtcl.so, btw:
[joeweb@rex lib]$ locate libtcl.so
/usr/lib/libtcl.so
/usr/lib/libtcl.so.0
I will try rebuilding pltcl.so and see if there are any error messages.
thanks,
janine
On 4/8/02 11:15 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> Janine Sisk <janine@furfly.net> writes:
>> Yesterday I installed Postgres 7.1.2 on Redhat 7.2. The install appeared to
>> go well, but createlang doesn't work:
>
>> [joeweb@rex joeweb]$ createlang pltcl joewebtest
>> ERROR: Load of file /usr/local/pgsql-7.1.2/lib/pltcl.so failed:
>> /usr/local/pgsql-7.1.2/lib/pltcl.so: undefined symbol: Tcl_CreateSlave
>> createlang: language installation failed
>
> Does the dynamic loader find libtcl.so? Running ldd on pltcl.so might
> be enlightening.
>
> FWIW, I see no problem with PG 7.1.3 built from source on stock RH 7.2.
> ldd pltcl.so shows
>
> libtcl.so.0 => /usr/lib/libtcl.so.0 (0x40023000)
> libdl.so.2 => /lib/libdl.so.2 (0x400a3000)
> libm.so.6 => /lib/i686/libm.so.6 (0x400a7000)
> libc.so.6 => /lib/i686/libc.so.6 (0x400ca000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>
> regards, tom lane
>
--
Janine Sisk
President/CEO
furfly.net, LLC
Mont Vernon, NH
Phone: 603-672-1122
On 4/8/02 11:15 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> Does the dynamic loader find libtcl.so? Running ldd on pltcl.so might
> be enlightening.
Well, there is no obvious error:
[postgres@rex tcl]$ make
gcc -pipe -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -fPIC
-I../../../src/include -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_GETCWD=1
-DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1
-DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1
-DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1
-DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1
-DSTDC_HEADERS=1 -DNEED_MATHERR=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1
-c -o pltcl.o pltcl.c
gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib
-ltcl -ldl -lieee -lm -lc
[postgres@rex tcl]$ ldd ./pltcl.so
libdl.so.2 => /lib/libdl.so.2 (0x4000f000)
libm.so.6 => /lib/i686/libm.so.6 (0x40013000)
libc.so.6 => /lib/i686/libc.so.6 (0x40036000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
This doesn't give me many clues... does anyone else see anything here?
BTW, although I've signed up for the mailing list I'm not actually getting
any list mail, so please cc me on any replise.
thanks,
janine
--
Janine Sisk
President/CEO
furfly.net, LLC
Mont Vernon, NH
Phone: 603-672-1122
On 4/8/02 12:56 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > You said before that you have libtcl in /usr/lib, so a reasonable bet is > that the ldconfig search path doesn't include /usr/lib at all ... > see the man page for ldconfig to check and fix it. The man page says /usr/lib is a trusted directory and always searched, but I added it to /etc/ld.so.conf anyway and ran ldconfig. When that didn't work, I tried adding /usr/lib to LD_LIBRARY_PATH - still no joy. I can't believe I'm the only person this is happening to; this is a stock standard RedHat install, it's not like I've done something funky to it! I'm having a serious case of "why me" right now... This looks reasonable to me: [postgres@rex tcl]$ ls -l /usr/lib/libtcl* lrwxrwxrwx 1 root root 11 Mar 17 20:51 /usr/lib/libtcl8.3.so -> libtcl.so.0 lrwxrwxrwx 1 root root 11 Mar 17 20:51 /usr/lib/libtcl.so -> libtcl.so.0 -r-xr-xr-x 1 root root 582774 Aug 29 2001 /usr/lib/libtcl.so.0 -rw-r--r-- 1 root root 1828 Aug 29 2001 /usr/lib/libtclstub.a Anything else I can try? thanks, janine -- Janine Sisk President/CEO furfly.net, LLC Mont Vernon, NH Phone: 603-672-1122
Janine Sisk <janine@furfly.net> writes:
> On 4/8/02 11:15 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> Does the dynamic loader find libtcl.so? Running ldd on pltcl.so might
>> be enlightening.
> Well, there is no obvious error:
> [postgres@rex tcl]$ make
> gcc -pipe -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -fPIC
> -I../../../src/include -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_GETCWD=1
> -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1
> -DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1
> -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1
> -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1
> -DSTDC_HEADERS=1 -DNEED_MATHERR=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1
> -c -o pltcl.o pltcl.c
> gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib
> -ltcl -ldl -lieee -lm -lc
> [postgres@rex tcl]$ ldd ./pltcl.so
> libdl.so.2 => /lib/libdl.so.2 (0x4000f000)
> libm.so.6 => /lib/i686/libm.so.6 (0x40013000)
> libc.so.6 => /lib/i686/libc.so.6 (0x40036000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> This doesn't give me many clues... does anyone else see anything here?
I believe this means that the dynamic loader isn't finding libtcl
(ldd seems to adhere to the "strong silent type" school of error message
design: if it fails to resolve a library reference, it simply doesn't
print anything :-().
You said before that you have libtcl in /usr/lib, so a reasonable bet is
that the ldconfig search path doesn't include /usr/lib at all ...
see the man page for ldconfig to check and fix it.
regards, tom lane
Janine Sisk <janine@furfly.net> writes:
> gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib
> -ltcl -ldl -lieee -lm -lc
Oh, oh, oh ... now I remember. See that -Wl,-soname,libtcl.so.0 switch?
That's causing pltcl.so to be marked internally with the soname
libtcl.so.0, thus the linker does not think it needs to link anything
else to resolve that reference. (This is arguably a bug in the Red Hat
RPMs for Tcl: they put that switch into the link arguments that the Tcl
config script advertises as being correct to use when trying to link
against Tcl. PG 7.2 has a defense against this, but 7.1.* did not.)
Probably your easiest fix is to manually repeat the link step for
pltcl.so with the -Wl bit removed, ie just
gcc -pipe -shared -o pltcl.so pltcl.o -L/usr/lib -ltcl -ldl -lieee -lm -lc
regards, tom lane
Yes, thanks Tom, that works!
My last two messages have been rejected from the list:
<pgsql-general@postgresql.org>: Command time limit exceeded:
"/usr/local/majordomo/bin/mj_email -r -d postgresql.org -l
pgsql-general"
so this one probably will be too; you might need to post your own followup
if you want one to be in the archives.
Thanks much!
janine
On 4/8/02 1:37 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> Janine Sisk <janine@furfly.net> writes:
>> gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib
>> -ltcl -ldl -lieee -lm -lc
>
> Oh, oh, oh ... now I remember. See that -Wl,-soname,libtcl.so.0 switch?
> That's causing pltcl.so to be marked internally with the soname
> libtcl.so.0, thus the linker does not think it needs to link anything
> else to resolve that reference. (This is arguably a bug in the Red Hat
> RPMs for Tcl: they put that switch into the link arguments that the Tcl
> config script advertises as being correct to use when trying to link
> against Tcl. PG 7.2 has a defense against this, but 7.1.* did not.)
>
> Probably your easiest fix is to manually repeat the link step for
> pltcl.so with the -Wl bit removed, ie just
>
> gcc -pipe -shared -o pltcl.so pltcl.o -L/usr/lib -ltcl -ldl -lieee -lm -lc
>
> regards, tom lane
>
--
Janine Sisk
President/CEO
furfly.net, LLC
Mont Vernon, NH
Phone: 603-672-1122
I think the problem may be that the libtcl.so is from the 7.2 that you originally had installed and is not compatible with the 7.1.2 That is normally the reason for these kind of problems Darren Ferguson On Mon, 8 Apr 2002, Janine Sisk wrote: > Mine is > > [joeweb@rex lib]$ ldd pltcl.so > libdl.so.2 => /lib/libdl.so.2 (0x4000f000) > libm.so.6 => /lib/i686/libm.so.6 (0x40013000) > libc.so.6 => /lib/i686/libc.so.6 (0x40036000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > So obviously the problem is that libtcl.so isn't linked in at all. I wonder > how I was able to build it at all? > > I do *have* libtcl.so, btw: > > [joeweb@rex lib]$ locate libtcl.so > /usr/lib/libtcl.so > /usr/lib/libtcl.so.0 > > I will try rebuilding pltcl.so and see if there are any error messages. > > thanks, > > janine > > On 4/8/02 11:15 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > > > Janine Sisk <janine@furfly.net> writes: > >> Yesterday I installed Postgres 7.1.2 on Redhat 7.2. The install appeared to > >> go well, but createlang doesn't work: > > > >> [joeweb@rex joeweb]$ createlang pltcl joewebtest > >> ERROR: Load of file /usr/local/pgsql-7.1.2/lib/pltcl.so failed: > >> /usr/local/pgsql-7.1.2/lib/pltcl.so: undefined symbol: Tcl_CreateSlave > >> createlang: language installation failed > > > > Does the dynamic loader find libtcl.so? Running ldd on pltcl.so might > > be enlightening. > > > > FWIW, I see no problem with PG 7.1.3 built from source on stock RH 7.2. > > ldd pltcl.so shows > > > > libtcl.so.0 => /usr/lib/libtcl.so.0 (0x40023000) > > libdl.so.2 => /lib/libdl.so.2 (0x400a3000) > > libm.so.6 => /lib/i686/libm.so.6 (0x400a7000) > > libc.so.6 => /lib/i686/libc.so.6 (0x400ca000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > > regards, tom lane > > > > -- > Janine Sisk > President/CEO > furfly.net, LLC > Mont Vernon, NH > Phone: 603-672-1122 > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
Tom Lane <tgl@sss.pgh.pa.us> writes: > Janine Sisk <janine@furfly.net> writes: > > On 4/8/02 11:15 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > >> Does the dynamic loader find libtcl.so? Running ldd on pltcl.so might > >> be enlightening. > > > Well, there is no obvious error: > > > [postgres@rex tcl]$ make > > gcc -pipe -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -fPIC > > -I../../../src/include -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_GETCWD=1 > > -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1 > > -DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1 > > -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 > > -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 > > -DSTDC_HEADERS=1 -DNEED_MATHERR=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1 > > -c -o pltcl.o pltcl.c > > gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib > > -ltcl -ldl -lieee -lm -lc > > > [postgres@rex tcl]$ ldd ./pltcl.so > > libdl.so.2 => /lib/libdl.so.2 (0x4000f000) > > libm.so.6 => /lib/i686/libm.so.6 (0x40013000) > > libc.so.6 => /lib/i686/libc.so.6 (0x40036000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > This doesn't give me many clues... does anyone else see anything here? > > I believe this means that the dynamic loader isn't finding libtcl > (ldd seems to adhere to the "strong silent type" school of error message > design: if it fails to resolve a library reference, it simply doesn't > print anything :-(). > > You said before that you have libtcl in /usr/lib, so a reasonable bet is > that the ldconfig search path doesn't include /usr/lib at all ... > see the man page for ldconfig to check and fix it. Doubt it, this sounds like the soname-bug where the created tcl component gets the same soname as the tcl library. Fixed in current beta of RHL and current version of PostgreSQL. -- Trond Eivind Glomsrød Red Hat, Inc.