[GRASS5] Tcl8.4 support?

[Glynn Clements]

Hamish wrote:

> > > But back to Debian with TclTk 8.4 and the bug as reported in
> > > http://article.gmane.org/gmane.comp.gis.grass.devel/1883
> > > 
> > > "it does freeze up (0% cpu) at the first instance of "exec"
> > > in etc/nviz2.2/scripts/nviz2.2_script, line 78:   (Adding panels
> > > section)    set panels [exec cat $index]
> > > 
> > > (I tried placing some exec's further up in the script & they did the
> > > same lock-up)"
> 
> G: One thing which might make a difference: try adding "-lpthread" to
> G: the link command. I've occasionally encountered all sorts of odd
> G: behaviour with programs which are linked against libraries which are
> G: linked against libpthread (typically libGL), but where the binary
> G: itself isn't linked directly against libpthread.
> 
> > I'll try tcl8.4 with "-lpthread" next.
> >  (added to src.contrib/GMSL/NVIZ2.2/src/Gmakefile  XTRA_LDFLAGS ?)
> 
> 
> That works(!)

Damn.

I have absolutely no idea how we could make configure detect this
situation.

Detecting whether libpthread exists is easy enough, but that isn't the
problem. Detecting whether libpthread is needed in order for linking
to succeed is also easy, but that isn't the problem either.

The problem is detecting whether linking NVIZ against libpthread will
make the situation better or worse, and that seems to be somewhere
between difficult and impossible.

The only easy solution is to provide a switch, e.g. --nviz-pthread,
which explicitly add -lpthread to the NVIZ linking switches. At least,
providing the switch is easy enough; dealing with user queries of the
form "what does this switch do and should I use it?" is likely to be
less straightforward.

> although I guess it really belongs somewhere else in the build system..?
> or is it a bug in the debian build of the tcl8.4 libraries? (as 8.3 works ok)

Possibly.

The problem is that linking against libpthread changes the behaviour
of a number of libc functions, including fork, wait, waitpid, open,
close, system, and anything to do with signal handling. These
functions are declared as weak symbols in libc, and are overriden by
libpthread.

I don't know this for sure, but I believe that what happens when a
program doesn't link against libpthread directly but links against a
library which links against libpthread is that the code in the
executable ends up using the libc versions but the code in the library
uses the libpthread versions.

What I do know for sure is that, in this situation:

a) non-trivial programs start behaving "strange", and

b) gdb (at least on RH6.2) exhibits specific strange behavior, i.e. 
everything stops working as soon as the program spawns any child
processes (e.g. calls system()).

AFAICT, any real fix would have to come from the developers of libc,
libpthread and/or ld-linux.so. [Or Linus could admit that the kernel
really does need to provide more than just clone(), which would
eliminate the need for most of the user-space "duct tape" which is at
the root of this problem.]

-- 
Glynn Clements <glynn.clements at virgin.net>