the tcl-8.3.3.ebuild and tk-8.3.3.ebuild automatically cause the --enable-threads flag on the ./configure line. (not affected by USE) I was trying to install lavaps-1.20 (http://www.isi.edu/~johnh/SOFTWARE/LAVAPS/index.html) which uses tcl/tk. lavaps built fine but crashed when trying to create a tcl intrepreter. I hacked the ebuilds for tcl and tk to not add the --enable-threads flag, emerged them again, rebuilt lavaps and it worked fine. I think the 2 ebuilds should be changed so that the use of the --enable-threads can be controlled by the USE environment variable. when tk was configuring, it even warns that enabling threads isn't a good idea. here's a stack dump from gdb when tcl/tk had threads enabled: 11:44pm1raven:/tmp/lavaps-1.20>gdb ./lavaps GNU gdb 5.1.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) run Starting program: /tmp/lavaps-1.20/./lavaps Program received signal SIG32, Real-time event 32. 0x40300ad9 in sigsuspend () from /lib/libc.so.6 (gdb) where #0 0x40300ad9 in sigsuspend () from /lib/libc.so.6 #1 0x4040ef59 in pthread_kill_other_threads_np () from /lib/libpthread.so.0 #2 0x4040e24b in pthread_create () from /lib/libpthread.so.0 #3 0x4014ac5d in Tcl_CreateThread () from /usr/lib/libtcl.so #4 0x4014b21f in Tcl_InitNotifier () from /usr/lib/libtcl.so #5 0x4012cc0a in TclInitNotifier () from /usr/lib/libtcl.so #6 0x4010f9aa in TclInitSubsystems () from /usr/lib/libtcl.so #7 0x400f3532 in Tcl_CreateInterp () from /usr/lib/libtcl.so #8 0x0804f4ef in tcl_blob::init () at tcl_blob.cc:335 #9 0x0804b4b1 in main (argc=1, argv=0xbffff9e4) at main.cc:127 #10 0x402ef3c1 in __libc_start_main () from /lib/libc.so.6 (gdb) The program is running. Exit anyway? (y or n) y
sounds like we should disable threads with tcl/tk
Disabled in tcl-8.3.3; will be a use flag later on when we have a consistent policy for handling ebuild-specific use flags.
Disabling threads blocks the aolserver (bug #17181) from being submited to portage because it requires tcl to be built with --enable-threads. Perhaps we could use an internal USE flag for the time being?
Created attachment 19633 [details] tcl ebuild with threads USE flag I've attached the modified tcl ebuild I'm using which has a 'threads' USE flag just in case its useful to anyone else. It makes merging <a href="http://bugs.gentoo.org/show_bug.cgi?id=17181">aolserver</a> easier.
Sorry. I don't have capacity to deal with the tcl and tk stuff anymore.
Stanislav, thoughts?
Stanislav, if you don't have any objections I'm going to go with the local USE flag. This bug is holding up 4 others.
so we could make "threads" as global flag it's also used in dev-lang/perl:threads - Enable Perl threads, has some compatibility problems
dev-lisp/clisp and dev-lisp/sbcl are two more ebuilds which can use a threads flag
I'd vote for a global threads flag. With the upcoming portage it could even be set per-package.
seemant: what do you think about a global threads USE-flag ?
marty, I don't know -- I think perl uses that -- but it's sort of a hidden flag because it could lead to dangerous things -- maybe sommething similar here?
perl team, please tell us about the threads flag a little more
Threads in perl will cause a number of compatibility problems as most people know. This is even more problematic in terms of things like mod_perl-like environments, from what I've heard. Very few perl apps or modules make use of threads due to their buggy nature and I think most people are willing to hold out for perl6 for a decent thread implementation. As long as it's not on by default, a threads USE flag is fine, but I wouldn't be surprised if we see a slight upswing in perl bugs because of it. I believe that the perl ebuild currently uses a env variable to handle enabling and disabling of threads - maybe this could be used for tcl as well? My concern is that someone will enable a threads use flag for tcl and all of sudden have wacky problems with perl.
If nobody has any objections, I'm going to goahead with this. I think i'll accompany a paused warning too. Anyone mind if I get rid of a few old ebuilds while I'm at it?
in CVS.
