Subject: Re: CVS commit: pkgsrc/lang/libtcl-nothread
To: Matthias Drochner <>
From: Jim Wise <>
List: tech-pkg
Date: 06/22/2004 17:23:41
Hash: SHA1

On Tue, 22 Jun 2004, Matthias Drochner wrote:

> said:
>> this is a crutch to avoid fixing packages which do not use the real
>> libtcl
>Imo, this is not about "fixing packages". One just can't load
>libpthread implicitely via dlopen() into a program which wasn't
>built against libpthread from the beginning. I believe so at least.
>There are two ways out: Either libtcl does something like libX11 -
>using the libc threadlib stubs, or we can't speak of a "real libtcl"
>-- we need a threaded and a non-threaded version. The former one
>would be pretty invasive, so I resorted to the latter.

You keep asserting this, but you have yet to explain away the other
tcl-using packages out there, many of which are dynamic modules for
other apps.

By your reasoning, pkgsrc/www/ap-dtcl should never work, yet I use it
regularly, for example.

>> show a single instance of a package which could
>> not, by linking correctly, be used with a correctly-compiled tcl
>postgresql-pltcl is an example. One could link against
>libpthread, but (unless someone convinces me that I'm wrong and

I use this package, and have not seen the problem you describe.
Perhaps instead of making assumptions about why it is failing for _you_
and modifying the package, you could send me the failure output you are

Incidentally, now that the freeze is over, I will be committing updated
pltcl and plperl packages for postgresql-7.4, both of which also work
fine here.

>linking in libpthread at runtime is harmless) I'm sure this would be
>a bad idea. I'm not going to doubt libpthread's stability (in 2.0
>at least), but it is unnecessary technically, and just not worth
>the risk.

Again, you keep asserting this, but you have not shown it to be the
case, nor explained away the many working tcl packages.

- -- 
				Jim Wise
Version: GnuPG v1.2.4 (NetBSD)