From f0c0c4d0f2d0c51fd89150f0ae900ccbd849ac18 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Mon, 2 Mar 2015 20:32:15 +0100 Subject: document that the pthread_threads assertion failure when dlopening libpthread is gone --- faq/libpthread_dlopen.mdwn | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'faq') diff --git a/faq/libpthread_dlopen.mdwn b/faq/libpthread_dlopen.mdwn index 94d091a4..e3401fdd 100644 --- a/faq/libpthread_dlopen.mdwn +++ b/faq/libpthread_dlopen.mdwn @@ -14,12 +14,13 @@ License|/fdl]]."]]"""]] Some applications don't themselves link against libpthread, but then load plugins which do link against libpthread. This means internally switching from -single-threading to multi-threading, which is [[not yet -supported|open_issues/libpthread_dlopen]] by our [[/libpthread]], and results -in errors such as: +single-threading to multi-threading, which is only supported since libc0.3 +2.19-16~2. Previously, it would result in errors such as: ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. -This can be worked around by making the application link against libpthread (i.e. not only the plugin, but also the main binary), or without recompiling by explicitly pre-loading libpthread, for example: +This could be worked around by making the application link against libpthread (i.e. not only the plugin, but also the main binary), or without recompiling by explicitly pre-loading libpthread, for example: $ LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3 [application] + +But it should now be gone, simply upgrade libc0.3. -- cgit v1.2.3