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

On 31/08/2007, Robert Edmonds <edmonds at debian.org> wrote:
> tags 440272 + patch
> thanks
>
> Graham Dumpleton wrote:
> > 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
>
> I'll offer an alternate theory.  From the python2.4 Debian changelog,
>
> python2.4 (2.4dfsg-1) unstable; urgency=medium
> [...]
>
>   * Replace md5 implementation with one having a DFSG conforming license.
>
> [...]
>  -- Matthias Klose <doko at debian.org>  Tue,  8 Feb 2005 19:13:10 +0100
>
> This implementation doesn't have the #define re-definitions, and
> unfortunately uses the same MD5* symbols used in other DSOs.  This patch
> ought to fix that.  Build-tested; the symbols are properly re-defined
> and the md5 module still works.
>
>
> --- python2.4-2.4.4/Modules/md5.h.orig  2007-08-31 04:32:55.778928580 -0400
> +++ python2.4-2.4.4/Modules/md5.h       2007-08-31 04:33:34.997163501 -0400
> @@ -45,6 +45,14 @@
>         UWORD32 in[16];
>  };
>
> +/* Rename all exported symbols to avoid conflicts with similarly named
> +   symbols in other libraries */
> +
> +#define MD5Init _PyDFSG_MD5Init
> +#define MD5Update _PyDFSG_MD5Update
> +#define MD5Final _PyDFSG_MD5Final
> +#define MD5Transform _PyDFSG_MD5Transform
> +
>  void MD5Init(struct MD5Context *context);
>  void MD5Update(struct MD5Context *context, md5byte const *buf, unsigned len);
>  void MD5Final(unsigned char digest[16], struct MD5Context *context);

Yeah, was thinking afterwards whether that might have been the case as
couldn't otherwise account for the MD5Transform function appearing as
that was made static in Python source code.

FWIW, I have updated by mod_wsgi documentation describing the problem.
See 'Python MD5 Hash Module Conflict' in:

  http://code.google.com/p/modwsgi/wiki/ApplicationIssues

Thanks for helping to track this problem. This has been hanging around
for a while, but we have never got enough information back from people
to identify exactly what the problem was caused by.

Graham