> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bernd Schmidt > Sent: den 21 juni 2007 16:25 > To: uClibc > Subject: libpthread vs libc dynamic link order > > In uClibc (when using linuxthreads.old), libc.so and > libpthread.so both > contain some functions with the same name, e.g. > _pthread_cleanup_push_defer. The version in libc tries to > forward the > call to a function found in a table called > __libc_pthread_functions in > libpthread. This table is initialized from an array called > __pthread_functions in pthread.c; this array contains a reference to > _pthread_cleanup_push_defer. > > Depending on the order in which the dynamic linker sees libc.so and > libpthread.so, this table in libpthread can refer to either > the function > in libc or the one in libpthread. We observed this with a Qt example > program: the executable was linked against libQtNetwork, > which in turn > was linked against libpthread, but the executable itself did not > reference libpthread.so. As a result, the dynamic linker > ended up with > an order where it picked the functions in libc.so over the ones in > libpthread.so, and when the forwarder function in libc is called, it > keeps looking up itself in the table, and calling itself. > > Is there a reason the forwarding functions in libc are > visible to other > shared libraries - it seems to me they are just for libc > internal use? > If not, the patch below seems to fix the problem here. Any > other ideas?
No other ideas, can't see a reason to export _X functions, but your patch hides all non _X funs too and that looks wrong. Not sure what the deal is with _ and __ funs, but there is probably a reason they aren't all __ or _ funs. Jocke _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
