Bugzilla Bug 2024

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 an attachment (id=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.