Bug 889784 - Distutils: Incorrect shared library extension on linux
Distutils: Incorrect shared library extension on linux
Product: Fedora
Classification: Fedora
Component: python3 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dave Malcolm
Fedora Extras Quality Assurance
Depends On: 922149
Blocks: PILLOW
  Show dependency treegraph
Reported: 2012-12-23 09:30 EST by Sandro Mani
Modified: 2013-04-01 06:55 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-01 06:55:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch (506 bytes, patch)
2012-12-23 09:30 EST, Sandro Mani
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Python 16754 None None None Never

  None (edit)
Description Sandro Mani 2012-12-23 09:30:05 EST
Created attachment 668051 [details]

Description of problem:
The find_library_file searches libraries with the python-versioned ".cpython-33m.so" extension, and hence always fails to find regular libraries.

Investigation shows that the library extension is being overridden by the one defined in the /usr/lib64/python3.3/config-3.3m/Makefile. The responsible line is
compiler.shared_lib_extension = so_ext
which overrides the default (and correct)
shared_lib_extension = ".so"
set at

A tentative patch is simply to comment out the statement at sysconfig.py::235 (patch attached).

See also upstream bug report http://bugs.python.org/issue16754

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Attempt to build a project with setuptools where the setup.py uses find_library_file
2. find_library_file will fail to find any regular shared library
Comment 1 Toshio Ernie Kuratomi 2013-01-09 18:15:11 EST
Note, this is one of the dependencies of the F19 Pillow feature which was approved by FESCo today.  dmalcolm: any ideas about whether we can move forward with the attached patch?
Comment 2 Dave Malcolm 2013-01-10 12:20:16 EST
(In reply to comment #1)
> Note, this is one of the dependencies of the F19 Pillow feature which was
> approved by FESCo today.  dmalcolm: any ideas about whether we can move
> forward with the attached patch?
For reference, this is: https://fedoraproject.org/wiki/Features/Pillow
Comment 3 Sandro Mani 2013-01-16 05:46:38 EST
May I ask for a quick status update on the bug? Essentially just to know whether I should post a pillow review request without the python3 subpackages for now, or whether it's worth waiting a little while longer for this to get fixed.

Comment 4 Toshio Ernie Kuratomi 2013-02-04 18:56:48 EST
I think we better get the package reviewed without this bug fixed otherwise it will get too late in the cycle to test it.
Comment 5 Sandro Mani 2013-02-05 17:59:56 EST
Ok, review posted, see bug #908114 . I really wish someone could rebuild python3 with the attached patch though...
Comment 6 Toshio Ernie Kuratomi 2013-02-28 11:13:49 EST
Hey dmalcolm, at yesterday's fesco meeting, we wondered if there was any update on this.  Even if it's a response of "I have no time, could someone else look into the following aspects of the patch:" it would help us know where things stand (and perhaps get someone to do some of the legwork.)
Comment 7 Dave Malcolm 2013-03-06 21:43:37 EST
Sorry for not getting around to this; I'm about to disappear for a week.

The analysis seems correct, and patch seems like a reasonable workaround.  Feel free to commit and rebuild.
Comment 8 Sandro Mani 2013-03-10 19:52:07 EDT
Could someone with sufficient privileges please do the rebuild? Thanks.
Comment 9 Toshio Ernie Kuratomi 2013-03-14 12:34:17 EDT
Rebuilt for rawhide.... For F19, getting a build failure:

I don't think it's related to the patch.  F-19 is having difficulties right now (although I wouldn't think it would cause this either).  I can have another try at building tonight or tomorrow night (at a conference so I'm only free occasionally).
Comment 10 Toshio Ernie Kuratomi 2013-03-15 04:19:30 EDT
dmalcolm analyzed this.and found that the problem is in the release name.  /etc/fedora-release has schrödinger in it.  the non ascii char is what is killi the platform.platform call.
Comment 11 Toshio Ernie Kuratomi 2013-03-15 11:17:01 EDT
For the UnicodeError:



Scratch build with the patch I created for that issue applied: http://koji.fedoraproject.org/koji/taskinfo?taskID=5126807

If that completes, I (or anyone else) can make a new build that fixes both that issue and this.
Comment 12 Toshio Ernie Kuratomi 2013-03-15 18:28:04 EDT
Fixed in

Please check if you are able to build the python3-pillow subpackages now.
Comment 13 Sandro Mani 2013-03-16 20:26:04 EDT
Thanks a lot Toshio. I'll push Pillow 2.0.0 with the python3 packages enabled as soon as I've found out why one of the tests hangs...
Comment 14 Sandro Mani 2013-04-01 06:55:42 EDT
This is now fixed.

Note You need to log in before you can comment on or make changes to this bug.