Package: libpcl1 Version: 1.6-1 I have a situation on the ARM platform where if I compile an executable to use both libpcl and libpthread, then even if I'm not actually using threads, trying to do anything to a coroutine causes an immediate segmentation fault.
To replicate:
$ gcc /usr/share/doc/libpc1-dev/examples/cobench.c -lpcl
--> produces working executable.
$ ldd ./a.out
libpcl.so.1 => /usr/lib/libpcl.so.1 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40029000)
/lib/ld-linux.so.2 (0x40000000)
gcc /usr/share/doc/libpc1-dev/examples/cobench.c -lpcl -lpthread
--> produces failing executable.
$ ldd ./a.out
libpcl.so.1 => /usr/lib/libpcl.so.1 (0x4001e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
libc.so.6 => /lib/libc.so.6 (0x40083000)
/lib/ld-linux.so.2 (0x40000000)
The reason why this is an issue is that I have an application which uses
coroutines, but not pthreads, which wants to link to the sqlite library. When
sqlite was built, it was done so with its threading support enabled; which
means that it tries to call mutex primitives in the pthreads library. This
means that linking an application against libsqlite will implicitly pull in
libpthread, which then causes it to fail.
This actually sounds suspiciously similar to a problem I previously
encountered on the i386, Debian bug 339827. To summarise: on i386 when running
a sufficiently old kernel that does not have thread-local storage, the
threading library figures out which thread is running by the location of the
stack pointer. If the application has allocated a user stack, it fails to cope
and crashes. This means that calling any thread-safe function which needs to
know what the calling thread is will fail when it is called from any user stack.
The only workaround I've got for this is to recompile sqlite without threading
support, which is painful.
Architecture:
Linux pyanfar 2.6.15-1-nslu2 #2 Tue Mar 7 17:36:32 UTC 2006 armv5tel GNU/Linux
Debian version:
Etch (current)
signature.asc
Description: OpenPGP digital signature
