mjhjmtu

The command

python -c "import imp; print(imp.get_suffixes())"

prints a list of tuples with suffixes used when importing modules (see the doc of imp.get_suffixes). Usually it is simply:

[('.so', 'rb', 3), ('module.so', 'rb', 3), ('.py', 'U', 1), ('.pyc', 'rb', 2)]

However, on Debian jessie, there is another suffix:

[('.x86_64-linux-gnu.so', 'rb', 3), ('.so', 'rb', 3), ('module.so', 'rb', 3), ('.py', 'U', 1), ('.pyc', 'rb', 2)]

and some extensions have the suffix .x86_64-linux-gnu.so, for example /usr/lib/python2.7/dist-packages/paraview/vtkCommonCorePython.x86_64-linux-gnu.so.

I would like to use extensions that have this suffix with a Python that is not the system Python and that I built myself, but it doesn't work because this Python doesn't have the suffix .x86_64-linux-gnu.so.

So I wonder how I can add this suffix. It seems that there is no function like imp.add_suffix. I suspect it is done during the building of Python but I wonder how... I looked at the source of the Debian Python packages, but it is not simple and I didn't manage to get how it works...

You should compile your not-system-python after configuring it with the same setup of Debian's python. One way to "retrieve" this is from the sysconfig module.

python -c "import sysconfig; print(sysconfig.get_config_vars()['CONFIG_ARGS'])"

gives you something like:

'--enable-shared' '--prefix=/usr' '--enable-ipv6' '--enable-unicode=ucs4' '--with-dbmliborder=bdb:gdbm' '--with-system-expat' '--with-system-ffi' '--with-fpectl' 'CC=x86_64-linux-gnu-gcc' 'CFLAGS=-D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security ' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'

which you would have to pass on to ./configure in the Python source directory.

Just got the same problem. Using the information provided in this thread I was able to go further.

I used apt source python2.7 and debuild -b -uc -us to inspect in detail how the official package was built. Implementation of imp.get_suffixes() is at Python/import.c:2940 imp_get_suffixes(...) which reads suffixes from list named _PyImport_Filetab. This list, in turn, is basically _PyImport_DynLoadFiletab and _PyImport_StandardFiletab concatenated.

It became obvious that _PyImport_DynLoadFiletab is what we should be looking for, and its definition varies for different platform - they are in Python/dynload_*.c. In Python/dynload_shlib.c is:

const struct filedescr _PyImport_DynLoadFiletab = 
#ifdef __CYGWIN__
 ".dll", "rb", C_EXTENSION,
 "module.dll", "rb", C_EXTENSION,
#else
#if defined(PYOS_OS2) && defined(PYCC_GCC)
 ".pyd", "rb", C_EXTENSION,
 ".dll", "rb", C_EXTENSION,
#else
#ifdef __VMS
 ".exe", "rb", C_EXTENSION,
 ".EXE", "rb", C_EXTENSION,
 "module.exe", "rb", C_EXTENSION,
 "MODULE.EXE", "rb", C_EXTENSION,
#else
#ifdef Py_DEBUG
 "_d.so", "rb", C_EXTENSION,
 "module_d.so", "rb", C_EXTENSION,
# ifdef MULTIARCH
 "." MULTIARCH "_d.so", "rb", C_EXTENSION,
# endif
#endif
#ifdef MULTIARCH
 "." MULTIARCH ".so", "rb", C_EXTENSION,
#endif
 ".so", "rb", C_EXTENSION,
 "module.so", "rb", C_EXTENSION,
#endif
#endif
#endif
 0, 0
;

It's right there: MULTIARCH, if you go look at the build log, is "x86_64-linux-gnu" (with quotes, because of the -s). The value is apparently from dpkg-architecture -qDEB_HOST_MULTIARCH but I have not verified.

More importantly, _PyImport_DynLoadFiletab does not look like this originally in dynload_shlib.c, it was patched. So to get the same behavior one must also apply some patch, at least add the "." MULTIARCH ".so", ... part. In my case patching this file (dynload_shlib.c) alone seems sufficient.