Subject: Re: CVS commit: pkgsrc/lang/libtcl-nothread
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: Jim Wise <firstname.lastname@example.org>
Date: 06/22/2004 17:23:41
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 22 Jun 2004, Matthias Drochner wrote:
>> this is a crutch to avoid fixing packages which do not use the real
>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
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 pltcl.so 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
>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
Again, you keep asserting this, but you have not shown it to be the
case, nor explained away the many working tcl packages.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
-----END PGP SIGNATURE-----