33211 2017-03-07 17:51:12 +0300 common filenames of .so modules are not recognized (after pip3 install) 2020-02-19 19:31:57 +0300 1 1 3 Distributions Branch p8 python3 не указана all Linux CLOSED FIXED P3 normal --- 33208 1 imz cas george glebfm grenka imz vitty vseleznv qa-p8 oldest_to_newest 162328 0 imz 2017-03-07 17:51:12 +0300 +++ This bug was initially created as a clone of Bug #33208 +++ python3-3.5.1-alt7 A difference between the commonly used (and recognized) filename for .so Python modules and the idea of ALT's python3's idea of it has been discovered (by george@) by trying to use a wheel-Python-package with .so modules: pip3 install pygame --user python3 -c 'import pygame.base' It includes a filename of a format like this: *.cpython-35m-x86_64-linux-gnu.so and is not recognized and loaded by ALT's python3. However, such filenames are generated and used also in Debian and Fedora -- here is an example from Fedora 25 for i386 and x86_64: $ rpm -qp python3-lxml-3.6.4-1.fc25.i686.rpm -l | fgrep .so /usr/lib/python3.5/site-packages/lxml/etree.cpython-35m-i386-linux-gnu.so /usr/lib/python3.5/site-packages/lxml/objectify.cpython-35m-i386-linux-gnu.so $ /usr/lib64/python3.5/site-packages/lxml/etree.cpython-35m-x86_64-linux-gnu.so /usr/lib64/python3.5/site-packages/lxml/objectify.cpython-35m-x86_64-linux-gnu.so contrary to filenames generated and recognized in ALT: $ rpm -q python3-module-lxml -l | fgrep .so /usr/lib64/python3/site-packages/lxml/etree.cpython-35m.so /usr/lib64/python3/site-packages/lxml/objectify.cpython-35m.so $ This could be fine, if the binaries were incompatible indeed, but they are loadable and usable after renaming (george@ checked this for pygame). (Some of ALT's patches changed this, probably, for no reason... This is a problem for using wheels installed by pip3 without recompilation.) (In reply to comment #2) > In Sisyphus, the fix of EXT_SUFFIX Python config parameter (bringing it to the > more common format) will be convenient to make together with the move to Python > 3.6. (The binary modules would anyway require a rebuild.) This is quite clear how to do. > (As for p8, this should be decided separately. Recognizing the common suffix in > addition to ours could be a solution with little hassle; otherwise, if we > change this parameter for the newly built modules, we'd need to track this with > Provides/Requires to ensure both kinds of modules would be usable.) This is less clear and requires hacking of a different piece of code (module finding). Patches (and tasks for p8) are welcome! See also: https://bugs.python.org/issue16754 which introduced the use of EXT_SUFFIX into the code. 188051 1 grenka 2020-02-19 19:31:57 +0300 * Mon Jul 10 2017 Fr. Br. George <george@altlinux.ru> 3.5.1-alt9 - Add PLATFORM_TRIPLET suffix for binary module search