Bug#599782: #599782 - pyopencl: FTBFS: ImportError: No module named pyopencl

[Jakub Wilk]

* Evgeni Golov <evg...@debian.org>, 2010-10-11, 18:54:

this one is "funny". setuptools uses python's os.uname() to check which
arch it is running on, and where the temp-build-path is. This fails
nicely on machines with 64bit-kernel and 32bit-userland (at least amd64,
as it has x86_86 in uname, as the kernel is for x86_64).

In this particular bug, it's not 64 vs 32 bit, but i686 vs i486, quoting
the build-log:

g++ -pthread -shared -Wl,-Bsymbolic-functions -g -O2

build/temp.linux-i686-2.6/src/wrapper/wrap_cl.o
build/temp.linux-i686-2.6/src/wrapper/wrap_cl_part_1.o
build/temp.linux-i686-2.6/src/wrapper/wrap_cl_part_2.o
build/temp.linux-i686-2.6/src/wrapper/wrap_constants.o
-lboost_python-py26 -lOpenCL -o build/lib.linux-i686-2.6/pyopencl/_cl.so

PYTHONPATH=../build/lib.linux-i486-2.6/ /usr/bin/make -C doc html

the stuff is built in build/lib.linux-i686-2.6/, but PYTHONPATH is set
to build/lib.linux-i486-2.6/. This is done in debian/rules:
PYTHONPATH=../build/lib.$(DEB_BUILD_ARCH_OS)-$(DEB_BUILD_GNU_CPU)-$(firstword
$(PYVERS))

There's another problem here: DEB_BUILD_* variables are used, but they are not defined anywhere. The code in question works only thanks to dpkg-buildpackage exporting these variables. It will fail (on any architecture) if debian/rules is run by hand.

$(DEB_BUILD_GNU_CPU) is wrong here, as is expands correctly to i486
(even on amd64 kernel with a i386 chroot).
I fear we have to "parse" `uname -m` here, to fix that issue and match
setuptools' algorithm.

The idiomatic approach to this problem is to use wildcards.

--
Jakub Wilk

signature.asc
Description: Digital signature