Bug 33211 - common filenames of .so modules are not recognized (after pip3 install)
Summary: common filenames of .so modules are not recognized (after pip3 install)
Status: CLOSED FIXED
Alias: None
Product: Branch p8
Classification: Distributions
Component: python3 (show other bugs)
Version: не указана
Hardware: all Linux
: P3 normal
Assignee: Andrey Cherepanov
QA Contact: qa-p8@altlinux.org
URL:
Keywords:
Depends on: 33208
Blocks:
  Show dependency tree
 
Reported: 2017-03-07 17:51 MSK by Ivan Zakharyaschev
Modified: 2020-02-19 19:31 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Zakharyaschev 2017-03-07 17:51:12 MSK
+++ 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.
Comment 1 Grigory Ustinov 2020-02-19 19:31:57 MSK
* Mon Jul 10 2017 Fr. Br. George <george@altlinux.ru> 3.5.1-alt9                 
- Add PLATFORM_TRIPLET suffix for binary module search