Graham Dumpleton wrote: > More information. In libmhash2 it has: > > lib/.libs/libmhash.a(md5.o): > 00000a60 T _MD5Final > 00000000 T _MD5Init > 00000040 T _MD5Transform > 00000940 T _MD5Update > U _mutils_bzero > U _mutils_memcpy > U _mutils_word32nswap > U dyld_stub_binding_helper > > In Python (<2.5), it has its own md5c.c file. If this is compiled > correctly, it should end up with: > > 00001288 T __Py_MD5Final > 00001174 T __Py_MD5Init > 000011b4 T __Py_MD5Update > > Ie., Python should prefix the symbols so there is no clash. > > You should check that this prefixing is actually occurring by doing an > nm on md5.so in Python modules directory. If it isn't, that could be > the problem.
It looks like this is not the case -- [EMAIL PROTECTED]:~$ nm -D /usr/lib/python2.4/lib-dynload/md5.so | grep MD5 0000000000001b30 T MD5Final 0000000000001380 T MD5Init 00000000000013b0 T MD5Transform 0000000000001c10 T MD5Update [EMAIL PROTECTED]:~$ nm -D /usr/lib/libmhash.so.2 | grep MD5 00000000000069b0 T MD5Final 0000000000006200 T MD5Init 0000000000006230 T MD5Transform 0000000000006a80 T MD5Update I guess this is the root cause of Debian bug #411487, but it looks like the submitter of #433038 still experiences his problem even when libmhash is not loaded into the apache process. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
