On Thursday 15 October 2009 02:41:10 Natanael Copa wrote: > 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.
i dont really understand what you're saying, but i'm pretty sure what you describe strictly doesnt matter. the stub forwarding symbols in uClibc check for libpthread availability at every function invocation. so loading it later rather than up front should be fine. not saying there isnt a problem somewhere, just that your brief theory is probably sniffing the wrong rabbit hole. > 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. people are testing post my commit fa8710bf5c7b0aaf7d687d9831fbd01b71da85ae ? -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
