GNOME Bugzilla – Bug 690347
does not find python include headers for multi-arch include files
Last modified: 2015-02-07 17:01:29 UTC
On the current Ubuntu development version, gobject-introspection fails to configure: checking for headers required to compile python extensions... not found configure: error: Python headers not found config.log says why: configure:14541: gcc -E -I/usr/include/python2.7 conftest.c In file included from conftest.c:45:0: /usr/include/python2.7/Python.h:8:22: fatal error: pyconfig.h: No such file or directory This is because pyconfig.h is architecture and configuration specific and thus the current Python packages ship this in a multiarch location (e. g. /usr/include/x86_64-linux-gnu/python2.7/pyconfig.h and also /usr/include/x86_64-linux-gnu/python2.7_d/pyconfig.h for the debug variant). When using python-config, the path is included: $ python2.7-config --includes -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 but m4/python.m4 does not use python*-config and instead hardcodes the assumption that the headers are in <prefix>/include/pythonVERSION/.
g-i does not actually build Python extensions, but the headers are required by giscanner/giscannermodule.c. One solution would be to call "$PYTHON-config --includes" instead of trying to collect all possible paths ourselves. Would that be acceptable?
Created attachment 231721 [details] [review] Use python-config instead of assuming include and library paths This simplifies m4/python.m4 and works here. But I'd appreciate if someone could test this on a current Fedora release as well?
or you can use pkg-config and search for python-2.7, which is easier as there are pkgconfig autoconf macros already.
(In reply to comment #3) > or you can use pkg-config and search for python-2.7, which is easier as there > are pkgconfig autoconf macros already. Yes, but we should fall back to the current case, as e.g. RHEL6 python-devel does not have a python-2.X.pc file (unfortunately).
Review of attachment 231721 [details] [review]: Nice, this looks better indeed. Works for me on RHEL6.
Comment on attachment 231721 [details] [review] Use python-config instead of assuming include and library paths Thanks for testing! Pushed. Please let me know if this causes problems anywhere, in which case we can switch this to "use -config if available, otherwise fall back to the previous method"; but that would make things even more complicated.
(In reply to comment #6) > (From update of attachment 231721 [details] [review]) > Thanks for testing! Pushed. > > Please let me know if this causes problems anywhere, in which case we can > switch this to "use -config if available, otherwise fall back to the previous > method"; but that would make things even more complicated. I meant for the pkg-config use suggested from comment #3. I doubt we'll need fallbacks for using "python-config", it's existed for a long time as far as I know. So we should be good, thanks!
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]