Deron Meranda
deron.meranda at gmail.com
Wed Jul 5 20:06:41 EDT 2006
On 7/5/06, Graham Dumpleton <grahamd at dscpl.com.au> wrote: > There is probably a shared library involved somewhere and they have > chosen names for functions which are the same as some functions > in some other library required by Python for md5 stuff. The libmhash > is probably getting loaded first and because they already exist, the > other libraries functions aren't being used but the wrong ones from > libmhash. Yes, except (unlike expat) I still can't figure out how they could conflict. The python md5module is completely self-contained--it doesn't call out to any external libraries except for the core python lib (and memcpy and memset). Unless something's pouncing on it's memory, or overriding something in the python dictionaries, I can't see what could be in conflict. Do we know if the python adapter "mhashmodule" was also loaded, or just libmhash? What might be interesting is to find the python md5module.so object file and see what symbols it is using. You might be able to do an "md5 -g" on it; or if not use "readelf -s" (ignoring LOCAL symbols). The only necessary global symbol is "initmd5" according to the Python C extension API. Also do a symbol lookup on the libmhash.so and mhashmodule.so and see if there are any external/global symbols in common. What's scary is that this alleged conflict is mostly silent. There are no crashes or obvious problems. It's just the the computed result is not what is expected. So who knows what other kinds of conflicts could exist that haven't been found yet! -- Deron Meranda
|