Python lib suffix detection flawed (kind of) #17
Comments
|
Ok, I've got some clues on what might be the problem here on ArchLinux. First things first. The compiler search path output is (libraries part in bold):
The python.m4 macro is based on the assupmtion that if there's a /lib64 suffix in the libraries search path, then we've got a 64-bit ABI. Arch uses that schema:
The compiler never outputs anything like "/lib32" or "/lib64", only "/lib", thus the detection code will never find anything and fall back to the first value of $libdirsuffix (which is kind of "ubuntish" anyway...). |
|
Python provides a pkgconfig file which we can use instead of the custom macro. I'll have a look. |
|
Can you try the below and see if it fixes the problem? diff --git a/configure.ac b/configure.ac
index f4059e3..66bc531 100644
--- a/configure.ac
+++ b/configure.ac
@@ -30,8 +30,12 @@ GTK_DOC_CHECK(1.9)
dnl **************************************************
dnl * Check for Python
dnl **************************************************
-AM_CHECK_PYTHON_HEADERS(,[AC_MSG_ERROR([could not find Python headers])])
-AM_CHECK_PYTHON_LIBS(,[AC_MSG_ERROR([could not find Python lib])])
+AM_PATH_PYTHON([2.6])
+PKG_CHECK_MODULES([PYTHON], [python-${PYTHON_VERSION}])
+PYTHON_LIB_LOC="pkg-config --variable=libdir'"
+AC_SUBST(PYTHON_LIBS)
+AC_SUBST(PYTHON_CFLAGS)
+AC_SUBST(PYTHON_LIB_LOC)
if test "`pkg-config --variable=datadir pygobject-3.0`" != "" ; then
PYGOBJECT_VERSION=pygobject-3.0
diff --git a/src/Makefile.am b/src/Makefile.am
index e3d7c3f..b9cbd55 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -16,12 +16,13 @@ libcaja_python_la_CPPFLAGS = \
-DLIBDIR=\"$(libdir)\" \
-DPYTHON_VERSION=\"$(PYTHON_VERSION)\" \
-DPY_LIB_LOC="\"$(PYTHON_LIB_LOC)\"" \
- $(PYTHON_INCLUDES) \
+ $(CAJA_PYTHON_CFLAGS) \
$(AM_CPPFLAGS)
libcaja_python_la_CFLAGS = \
+ $(PYTHON_CFLAGS)
$(CAJA_PYTHON_CFLAGS) \
$(AM_CFLAGS)
libcaja_python_la_LDFLAGS = -module -avoid-version
-libcaja_python_la_LIBADD = $(CAJA_PYTHON_LIBS) $(PYTHON_LIBS)
+libcaja_python_la_LIBADD = $(PYTHON_LIBS) $(CAJA_PYTHON_LIBS) |
|
The compilation failed for this patch: If it helps anything, Arch is building python-caja based on this source package: http://pub.mate-desktop.org/releases/1.8/python-caja-1.8.0.tar.xz |
|
I suck 😢 and messed up the patch. New version here https://github.com/infirit/python-caja/commit/6ed4ebcf1af8eaead423de1aefe2642f2d75a979.diff. PS: Do make sure to run autoreconf -fi to regen the build system before running configure 😄 |
|
It works. 😄 Thanks infirit! |
|
Excellent, pushed as 6ed4ebc. |
Hi.
This won't be very precise as my knowlegde of automake tools quite limited, but I found a little bug. It's for the current version. The python.m4 macro has some code that evaluates the libdirsuffix variable, later used in the PYTHON_LIB_LOC variable and so on. The libdrisuffix is hardcoded with the "/i386-linux-gnu/".
Here's the problem: the evaluation of the libdirsuffix variable passes without making changes to the initial value. This results in a "/i386-linux-gnu/" suffix... on a 64-bit environment... where the directory doesn't exist. ;)
This results in an error when trying to load a Python extension (RabbitVCS Caja extension in my case):
The workaround for me was to change the hardcoded "/i386-linux-gnu/" to just "/", but it seems that the path evalution code didn't do anything on my environment. I'm using ArchLinux 64-bit. The basic directory structure for the lib directories is:
I didn't have too much time to dig into the evaluation code (at work right now and really needed that SVN integration), but if I find anything else, I'll post it here. If there's anything else you would need to know, I'll be happy to add it.
The text was updated successfully, but these errors were encountered: