[mod_python] Re: Debian bug#433038: mod_python collides with mod_php5

On 31/08/2007, Robert Edmonds <edmonds at debian.org> wrote:
> 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 --
>
> edmonds at chase{0}:~$ nm -D /usr/lib/python2.4/lib-dynload/md5.so | grep MD5
> 0000000000001b30 T MD5Final
> 0000000000001380 T MD5Init
> 00000000000013b0 T MD5Transform
> 0000000000001c10 T MD5Update
>
> edmonds at chase{0}:~$ 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.

I think I know what may have gone wrong here.

In Python source code there is md5c.c and md5.h. In the md5.h file it has:

/* Rename all exported symbols to avoid conflicts with similarly named
   symbols in some systems' standard C libraries... */

#define MD5Init _Py_MD5Init
#define MD5Update _Py_MD5Update
#define MD5Final _Py_MD5Final

void MD5Init(MD5_CTX *);
void MD5Update(MD5_CTX *, unsigned char *, unsigned int);
void MD5Final(unsigned char [16], MD5_CTX *);

If when the Python package was Debianised, whoever did it added
additional -I flags at the start of the CPPFLAGS passed to the
compiler such that instead of picking up md5.h from the Python source
directory, it picked up one from some system include directory, or
from another package, then the symbols would not have been namespace
prefixed like they should have.

As a result, just for Debian package of Python, the symbols wouldn't
be namespaced and thus why this problem only appears on Linux systems
derived from Debian packages.

The only way therefore of fixing this may be to review the Debian
package build scripts around Python to see if they do do something
with -I as a described. Simple fix may then be to append the -I flags
rather than prepend them. Otherwise, would be necessary to patch
md5c.c in Python source code to move the #defines into it just before
"md5.h" is included. That way the namespace prefixing will occur even
if wrong "md5.h" is included. One would hope though in this case that
the "md5.h" file actually used is compatible with the md5c.c file in
Python.

Graham