GNOME Bugzilla – Bug 509023
Incorrect assumptions about locations of python headers/libs
Last modified: 2008-01-14 19:11:20 UTC
gnumeric-1.8.0 configure makes some non-portable assumptions about how python installed (certain specific subdirs of sys.prefix), and as a result needs lots of manual intervention (env vars) to get the python headers and libraries accessed correctly. Instead of assuming a certain filesystem layout, much simpler to just query python itself, which already knows the location of the headers and library (on *all* platforms, including I presume win32, and even if python was installed in a non-standard way). The directory containing the python headers is: distutils.sysconfig.get_python_inc() and the directory containing the libpython shared library is: distutils.sysconfig.get_config_var("LIBPL")
Created attachment 102690 [details] [review] Get -I and -L paths from python itself
Unfortunately we can't do that. It breaks win32 cross compilation, which is the only way we do a windows build just now. An acceptable alternative would be to use python to extract the paths by default, but allow the env vars to override that.
I don't know the details of the cross-compiling you are doing, but PY_PREFIX is not used except for setting PY_INCLUDE_DIR and PY_LIB_DIR, and I intentionally did leave those two variables overrideable by the shell. Thus the include and lib paths could be set to whatever cross-compiling locations are needed (libs/ instead of lib/, some non-standard headers location, etc).
These are the lines you should concentrate on: PY_INCLUDE_DIR="$PY_PREFIX/include/python$PY_VERSION" PY_LIB_DIR="$PY_PREFIX/lib" They can go and ask python if that is useful, but everything needs to be overrideable for any kind of cross compilation -- the compile system's python simply cannot know about the target system's python.
Created attachment 102699 [details] [review] More flexible over-riding opportunities My original patch allows complete over-riding and ignoring of the compile-system's python using PY_INCLUDE_DIR and PY_LIB_DIR exactly as in the existing configure script (the compile machine's python is interrogated *only if* those variables are not already set). If you prefer to keep PY_PREFIX as an alternative as well, here's the more limited patch.
NB, my patches also include fix for Bug #508988...that breakage interfered with my ability to test the situation at hand here.
Visually looks fine to me, except for this: - GNM_PY_CFLAGS="-I $PY_INCLUDE_DIR $PYGOBJECT_CFLAGS" - GNM_PY_LDFLAGS="-L $PY_LIB_DIR -lpython$PY_VERSION $PYGOBJECT_LDFLAGS" + GNM_PY_CFLAGS="-I$PY_INCLUDE_DIR $PYGOBJECT_CFLAGS" + GNM_PY_LDFLAGS="-L$PY_LIB_DIR -lpython$PY_VERSION $PYGOBJECT_LIBS" Is there a reason for mucking with the whitespace that I cannot think of?
> Is there a reason for mucking with the whitespace that I cannot think of? > Please read Comment #6.
Your patch didn't apply cleanly, so I had to hand-edit a bit. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.