On Mon, Feb 12, 2007 at 10:12:09PM +0200, [EMAIL PROTECTED] wrote:
> On Mon, Feb 12, 2007 at 06:04:36PM +0100, Karel Kulhavy wrote:
> >  16287 yes      CALL  #243 (unimplemented linux_sys_set_thread_area)()
> >  16287 yes      PSIG  SIGSYS SIG_DFL code 0
> >  16287 yes      NAMI  "yes.core"
> > 
> > What does this mean? That linux_sys_set_thread_area is unimplemented in the 
> > emulation?
> >
> 
> IIRC, it's like that:
> 
> The linux ld-linux.so dynamic linker calls uname(), gets the version
> of the kernel (4.0 on OpenBSD), and based on the fact that 4.0 > 2.5.58
> (or something similar) decides that you're running a 2.6.X NPTL-able
> kernel, and goes on to set up things for NTPL threads with
> set_thread_area(), etc, even if the program is a non-threaded one.
> 
> The solution to that is to run the linux binary with
> 
> LD_ASSUME_KERNEL=2.4.2
> 
> in the environment.

Now I avoided the NTPL problem by removing the redhat base and copying
only the libraries that printed an error that it wants them. But when I
copied libstdc++.so.6 it now print:
[EMAIL PROTECTED]:~$ ./ekiga
./ekiga: error while loading shared libraries: libstdc++.so.6: cannot handle
TLS data

I tried to google but didn't find any information what it means. Probably
not Transport Layer Security. Any idea somehow who understands this C++ stuff?

CL<

Reply via email to