On Wed, 2009-10-14 at 09:20 -0700, Cuero Bugot wrote: .. > The prb is that I get a segfault when I try to use pthread_create from > a dynamically linked library. The difference with the above fix use > case is that I "manually" link the library using dlopen. I initially > found this prb while trying to use the Lua (www.lua.org) VM with > uclibc. Lua supports loading extension as so files so it uses dlopen. > > I reduced and reproduced the prb with this simple use case: > > 2 files (attached): test.c and lib.c > test.c contains the main() that will load the so file compiled from lib.c. > lib.c actually creates a thread. (well crashed when trying to create a > thread).
Yes. I have had this too for a long time[1] and I also made a testcase[2] for this. I think it hs to do with uclibc having some non-pthread funcs that is used when pthread is not linked in. So when you dlopen something linked to pthread, the pthread version of the symbols should have been used, but they arent, since pthread was not there during first link. The apps that this affects is scripting languages lua, ruby and php[3] together with the sqlite3 binding. I think it also affects cpufreqd. The way I have worked around it is to force linking to pthread in the main binary[4][5][6]. I havent bothered to try fix it in uClibc since we soon will have NTPL. [1] https://bugs.gentoo.org/show_bug.cgi?id=189804 [2] http://dev.alpinelinux.org/~ncopa/dl-pthread/ [3] http://redmine.alpinelinux.org/issues/show/183 [4] http://git.alpinelinux.org/cgit/aports/commit/?id=13892e864cacf21636be25149eabcd3e2537f7aa [5] http://git.alpinelinux.org/cgit/aports/commit/?id=8853a68804a505e1af90ccbbfc9295551a5d3a6c [6] http://git.alpinelinux.org/cgit/aports/commit/?id=9881efaf35fb10a9145a18d71f9af6f019ccab81 -nc _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
