Python.h should be included first

• Key: MODPYTHON-138
• Type: Bug
• Status: Open
• Priority: Major
• Assignee: Jim Gallacher
• Reporter: Michel Jouvin
• Component/s: core
• Affects Version/s: 3.2.7

Description

I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. This change should have no impact on platforms where the current include order works.

Affected files are :

      src/include/psp_parser.h
      src/include/mod_python.h
      src/include/psp_flex.h
      src/include/mod_python.h.in
      src/_pspmodule.c
      src/psp_parser.c

I have a patch file available, I'll try to attach it to this issue if I manage to find how to do it...

Michel

Comments

[Michel Jouvin]

Diff file containing changes implemented to fix the issue described. Built for 3.2.6 but should probably works with any 3.2.x.

Michel's patch does not work for Debian Linux. mod_python immediately segfaults. There was a different gcc warning, which I had not seen before:

/usr/bin/libtool --silent --mode=compile gcc -prefer-pic -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -g -O2 -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -g -O2 -pthread -I/usr/include/apache2 -I/usr/include/apr-0 -I/usr/include/apr-0 -I/usr/include -I/tmp/mod_python/src/include -I/usr/include/apache2 -I/usr/include/python2.3 -c -o _apachemodule.lo _apachemodule.c && touch _apachemodule.slo
In file included from /usr/include/python2.3/Python.h:8,
                 from /tmp/mod_python/src/include/mod_python.h:46,
                 from _apachemodule.c:25:
/usr/include/python2.3/pyconfig.h:865:1: warning: "_XOPEN_SOURCE" redefined
<command line>:1:1: warning: this is the location of the previous definition

[Jim Gallacher]

I should have added that a similar error occurs 9 more times.

[Graham Dumpleton]

Suggest this be put on hold anyway until original poster actually attaches here the original output from the build, including compiler options and error output.

I suggest this, as their original comment:

  "When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value."

makes no sense. If header files are correctly protected with #ifndef they shouldn't be able to be included twice. Thus more information needed about the actual error message and which header files is supposedly being included twice, so it can be debugged properly rather than trying to solve it by just shifting stuff around.