mailing-list for TeXmacs Users

["David G. Wonnacott" <address@hidden>]

   Date: Tue, 1 Aug 2006 13:20:15 +0200
   From: Joris van der Hoeven <address@hidden>

   On Tue, Aug 01, 2006 at 10:31:48AM +0200, Jean BOYABE wrote:
   > cannot handle file 'libc.so.6' with TLS data

   Hmm, I have been searching on the web and found one interesting page in 
French:

           http://linuxfr.org/~houplaboom/7900.html

   Please check whether you have a directory

           /usr/lib/tls

   If so, then move it to a safe place

           su -
           mv /usr/lib/tls /usr/lib/tls.bak

   and try again. This might work.

   Other references to this problem:

           http://articles.involution.com/tls.php
           http://www.nvnews.net/vbulletin/showthread.php?t=10968

   I still don't understand whether something is wrong on the machine
   on which I build the binaries or on machines running certain
   new distributions. Someone can help?

   Best wishes, Joris

I can't add much, but here's what I've found -- I had the same problem
when I tried the staticly linked texmacs from the web site. I don't
have a /usr/lib/tls, but there is a /lib/tls, and when I rename that,
I just get "segmentation fault" when I run texmacs.

I tried running texmacs.bin from within gdb (after setting the various
environment variables I saw in the texmacs script). I noticed that gdb
prints out information about thread libraries when texmacs starts; it
says either:

        Using host libthread_db library "/lib/libthread_db.so.1".

when /lib/tls is not there (and then texmacs goes on to segmentation
fault), or

        Using host libthread_db library 
"/lib/tls/i686/cmov/libthread_db.so.1".

when /lib/tls is there, as it is supposed to be on this system (and
then texmacs goes on to complain about TLS data).

Note that either of these errors is reported by gdb, suggesting to me
that the error is actually coming from the execution of texmacs.bin
rather than some helper program texmacs starts.

I believe we have some sort of multithreading option turned _on_ for
our system to support cluster computing. Perhaps this has some impact
on the thread library? And perhaps the thread library _cannot_ be
statically linked for some reason? I'm just guessing on these.

If you want to put out a staticly linked binary with the -g option for
debugging, I'll tell you where it actually blows up, if you like, but
presumably the segmentation fault is not worth tracking down (since it
only occurs on an inconsistently configured system) and the complaint
about TLS data will just be in some initialization inside the tls
version of the thread library or something.

I hope this helps,

Dave Wonnacott

P.S. for the time being, I'll be using the version I compile from the
CVS sources, and just manually converting my .jpg's into .ps or .pdf.
And thus the staticly linked version is not really important to me.
But any more light on the image inclusion matter would be appreciated.