tcl port and thread enabling

Gustaf Neumann neumann at wu-wien.ac.at
Thu Jan 12 02:41:14 PST 2012


Dear all,

some additional info: As a test i de-installed tcl and all 
tcl-dependent Tcl ports from my machine and re-installed new 
with the threaded tcl "variant". Then i installed all 
packages having tcl in their names based on threaded tcl. 
Certainly, this is not a full list, there are certainly more 
packages depending from tcl (sometime in variants of these 
packages).

 From this selection the exactly same ports could be 
compiled/installed with the threads variant as the 
non-threaded packages. Non working tcl ports are:

otcl, tclcl (both are the same source, seems to depend on 
tcl8.4, there is a bug report in the tracker)
tclx (seems to depend on tcl 8.4, Portfile tries to cp files 
from tcl8.4.14-privateheaders, but report in tracker)
tcLex (depends on internal tcl headers, frequent problem 
with tcl packages)
tcl-tls (missing configure flag, will provide a patch)
tclreadline  (compiles nicely, crashes during runtime with 
alloc: invalid block: ..., has broken source, will provide a 
patch)

afitk, all these ports work as good/bad with and without 
threads enabled.

-gustaf neumann

-------- Original-Nachricht --------
Betreff: 	Re: tcl port and thread anabling
Datum: 	Wed, 11 Jan 2012 19:27:48 +0100
Von: 	Gustaf Neumann <neumann at wu.ac.at>
An: 	macports-users at lists.macosforge.org



Am 11.01.12 18:02, schrieb Stephen Langer:
>  On Jan 11, 2012, at 11:09 AM, Ryan Schmidt wrote:
>
>>  If enabling threads in tcl will not cause any problems, then we should remove the variant, enable threads all the time, and revbump tcl and all ports that use it to force a rebuild.

i think this would the best option....

>>
>>  But if there is still a valid reason why we'd sometimes want threads and sometimes not, then really we should have a tcl-threads subport within the tcl port, work should be done so that both tcl and tcl-threads can be installed simultaneously and not conflict with one another, and all ports that use tcl should decide whether they want threads support or not and depend on either tcl or tcl-threads.

I can certainly not guarantee, that there is no package that might run
into troubles with thread-enabled Tcl - especially with broken packages
- but  when the other distros do it, it should not be a catastrophe. i
can certainly offer my help if the change causes troubles. In the worst
case, we should find a way to make e.g. a non-threaded Tcl package and
use this as a dependency for the code not working with the
multi-threaded Tcl. The majority of packages will work with the multi
threaded Tcl.


  >  The right thing to do is for all libraries to allow threads to be enabled or disabled at *run* time, not compile time.

it is not realistic for tcl to turn threading on/off at runtime. The Tcl
code (and many dependent packages)
contains code like the following
...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20120112/fe0caffd/attachment.html>


More information about the macports-users mailing list