Horton
Menu

Thread

  1. Pl/Tcl problem

    Alvaro Herrera <alvherre@atentus.com> — 2001-12-14T22:25:06Z

    Hello:

I'm having trouble creating the Pl/Tcl language in RedHat Linux 7.1.
When I issue the createlang command I get this:

[replicator@att-stgo-1 replicator]$ createlang -L /usr/lib/pgsql pltcl
replicator
ERROR:  Load of file /usr/lib/pgsql/pltcl.so failed:
/usr/lib/pgsql/pltcl.so: undefined symbol: Tcl_CreateSlave
createlang: language installation failed

Of course /usr/lib/pgsql/pltcl.so exists, and /usr/lib/libtcl8.3.so does
exist also. They both were installed via the RedHat 7.1.3 RPMs (not
Lamar Owen ones). Strange thing is Tcl_CreateSlave is defined in
/usr/lib/libtcl8.3.so, which is not in the output of ldd here in RedHat.
BUT I've succesfully installed Pl/Tcl from source (7.2b4) at home in
Mandrake Linux and libtcl8.3.so appears in the ldd output for pltcl.so.
I don't know what to think, and have no idea whatsoever about Tcl for
debugging this kind of stuff.

Of course I don't think the RPMs are flawed, but I can't find what the
problem is. Any clue?

Thanks,

-- 
Alvaro Herrera (<alvherre@atentus.com>)

  2. Re: Pl/Tcl problem

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-14T22:49:40Z

    First guess is that libtcl.so is not in the ldconfig database.

			regards, tom lane

  3. Re: Pl/Tcl problem

    Trond Eivind Glomsrød <teg@redhat.com> — 2001-12-14T22:58:50Z

    Alvaro Herrera <alvherre@atentus.com> writes:

> Hello:
> 
> I'm having trouble creating the Pl/Tcl language in RedHat Linux 7.1.
> When I issue the createlang command I get this:
> 
> [replicator@att-stgo-1 replicator]$ createlang -L /usr/lib/pgsql pltcl
> replicator
> ERROR:  Load of file /usr/lib/pgsql/pltcl.so failed:
> /usr/lib/pgsql/pltcl.so: undefined symbol: Tcl_CreateSlave
> createlang: language installation failed
> 
> Of course /usr/lib/pgsql/pltcl.so exists, and /usr/lib/libtcl8.3.so does
> exist also. They both were installed via the RedHat 7.1.3 RPMs (not
> Lamar Owen ones). Strange thing is Tcl_CreateSlave is defined in
> /usr/lib/libtcl8.3.so, which is not in the output of ldd here in RedHat.
> BUT I've succesfully installed Pl/Tcl from source (7.2b4) at home in
> Mandrake Linux and libtcl8.3.so appears in the ldd output for pltcl.so.
> I don't know what to think, and have no idea whatsoever about Tcl for
> debugging this kind of stuff.
> 
> Of course I don't think the RPMs are flawed, but I can't find what the
> problem is. Any clue?

The language module for tcl is created with soname libtcl.so.0. This
is the same soname used by libtcl... creating confusion for the linker.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

  4. Re: Pl/Tcl problem

    Trond Eivind Glomsrød <teg@redhat.com> — 2001-12-14T23:14:40Z

    Tom Lane <tgl@sss.pgh.pa.us> writes:

> First guess is that libtcl.so is not in the ldconfig database.


Nah, the problem is that the module is created like this:

gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib -ltcl -ldl  -lieee -lm -lc

The pltcl.so module thus has soname libtcl.so.0. That leads to
problems, as the same soname is used by the tcl library.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

  5. Re: Pl/Tcl problem

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-15T05:35:25Z

    teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> Nah, the problem is that the module is created like this:
> gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib -ltcl -ldl  -lieee -lm -lc
> The pltcl.so module thus has soname libtcl.so.0. That leads to
> problems, as the same soname is used by the tcl library.

Ugh.  Is this our fault, or Tcl's?

			regards, tom lane

  6. Re: Pl/Tcl problem

    Trond Eivind Glomsrød <teg@redhat.com> — 2001-12-15T14:19:04Z

    On Sat, 15 Dec 2001, Tom Lane wrote:

> teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> > Nah, the problem is that the module is created like this:
> > gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib -ltcl -ldl  -lieee -lm -lc
> > The pltcl.so module thus has soname libtcl.so.0. That leads to
> > problems, as the same soname is used by the tcl library.
> 
> Ugh.  Is this our fault, or Tcl's?

I'm not sure. One thing which probably affects it, is that we have a 
proper soname for libtcl (in addition to the nonstandard library name), 
which we're trying to upstream. What I'm not sure of is where soname for 
the postgresql tcl module comes from - "libtcl.so.0" is not a sane one to 
use.   

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

  7. Re: Pl/Tcl problem

    Alvaro Herrera <alvherre@atentus.com> — 2001-12-15T15:58:23Z

    On Sat, 15 Dec 2001, Trond Eivind Glomsrød wrote:

> On Sat, 15 Dec 2001, Tom Lane wrote:
>
> > teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> > > Nah, the problem is that the module is created like this:
> > > gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib -ltcl -ldl  -lieee -lm -lc
> > > The pltcl.so module thus has soname libtcl.so.0. That leads to
> > > problems, as the same soname is used by the tcl library.
> >
> > Ugh.  Is this our fault, or Tcl's?
>
> I'm not sure. One thing which probably affects it, is that we have a
> proper soname for libtcl (in addition to the nonstandard library name),
> which we're trying to upstream. What I'm not sure of is where soname for
> the postgresql tcl module comes from - "libtcl.so.0" is not a sane one to
> use.

I'd say it's the RPM packaging, for my problem was solved as soon as I
used the source version of pltcl.so without touching Tcl or anything
else. Can't prove that though.

-- 
Alvaro Herrera (<alvherre[@]atentus.com>)
"Los romanticos son seres que mueren de deseos de vida"

  8. Re: Pl/Tcl problem

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-15T17:13:41Z

    =?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= <teg@redhat.com> writes:
> On Sat, 15 Dec 2001, Tom Lane wrote:
>> teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
>>> Nah, the problem is that the module is created like this:
>>> gcc -pipe -shared -Wl,-soname,libtcl.so.0 -o pltcl.so pltcl.o -L/usr/lib -ltcl -ldl  -lieee -lm -lc
>>> The pltcl.so module thus has soname libtcl.so.0. That leads to
>>> problems, as the same soname is used by the tcl library.
>> 
>> Ugh.  Is this our fault, or Tcl's?

> I'm not sure. One thing which probably affects it, is that we have a 
> proper soname for libtcl (in addition to the nonstandard library name), 
> which we're trying to upstream. What I'm not sure of is where soname for 
> the postgresql tcl module comes from - "libtcl.so.0" is not a sane one to 
> use.   

It looks like src/pl/tcl/Makefile uses this to build pltcl.so:

%$(TCL_SHLIB_SUFFIX): %.o
	$(TCL_SHLIB_LD) -o $@ $< $(TCL_LIB_SPEC) $(SHLIB_EXTRA_LIBS)

where TCL_SHLIB_LD is taken verbatim from tclConfig.sh.  I infer that
on your platform, TCL_SHLIB_LD expands to
	gcc -pipe -shared -Wl,-soname,libtcl.so.0
which is a somewhat reasonable thing for it to expand to when building
libtcl.so, but not really what we want for pltcl :-(

Perhaps we should abandon the idea of relying on Tcl's definitions to
tell us how to build the shlib.  IIRC, that decision was made a long
time ago before we had the present Makefile.shlib support, when it made
sense to assume Tcl might know more than we do about how to build
shlibs.

But I'm not sure that this has anything to do with Alvaro's problem.
The bogus choice of soname has doubtless been that way for awhile,
and yet we've not had other complaints.

			regards, tom lane

  9. Re: Pl/Tcl problem

    Trond Eivind Glomsrød <teg@redhat.com> — 2001-12-15T17:17:35Z

    Tom Lane <tgl@sss.pgh.pa.us> writes:

> But I'm not sure that this has anything to do with Alvaro's problem.
> The bogus choice of soname has doubtless been that way for awhile,
> and yet we've not had other complaints.

Biggest reason: Hardly anyone uses tcl.

We've shipped it that way, and there was one complaint month after we
shipped... Comparing that to feedback on other areas in the same
package, I just don't think the tcl functionality is used much. Tcl is
exactly all the rage anymore.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.