1 |
If Coro causes segfaults a lot on calls to libc functions, the cause is |
2 |
probably a glibc compiled for i386 and kernel 2.2. |
3 |
|
4 |
Glibc contains a bug that causes any program linked against pthreads AND |
5 |
using coroutines (of any kind, not only Coro, but including most userspace |
6 |
thread libraries like gnu-pth) or alternate stacks to segfault on calls to |
7 |
pthread functions. And glibc happens to do a lot of these calls. |
8 |
|
9 |
(Even if you pelr is not compiled against pthreads, Time::HiRes links |
10 |
against -lrt, which drags in pthreads. The same is true for other modules, |
11 |
so watch out). |
12 |
|
13 |
The bug is rather difficult to fix. This is not a problem, however, since |
14 |
glibcs compiled for linux-2.4 use a much more efficient method to locate |
15 |
their data, which happens to work with coroutines. |
16 |
|
17 |
So the easy fix is to install a libc which was compiled for linux-2.4, |
18 |
using the "--enable-kernel=2.4 i586-pc-linux-gnu" configure options. |
19 |
|
20 |
WARNING: This libc will no longer run on linux-2.2 or lower! |
21 |
|
22 |
UPDATE: I am no longer able to compile glibc-2.3.2 in this way. The reason |
23 |
is most probably that the glibc folks work on an enhanced thread local |
24 |
storage facility, and it might be that you need a 2.5 or 2.6 kernel to |
25 |
make it work. Glibc-2.3.1 works fine, though. |