jwise@draga.com 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.

> 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 pltcl.so against
libpthread, but (unless someone convinces me that I'm wrong and
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.

> if we follow the logic by which you created this
> package, you should immediately create a lang/libtcl-nolibm package

The difference is that libm can be linked into a running process
without side effects.

best regards
Matthias