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<