Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Tue, 21 Jan 2014 09:55:13 -0800
From: Mark Heieis <mheieis@alois.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: python-list@python.org
Subject: autoconf tools and python3 3m 3dm
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5801.1390326925.18130.python-list@python.org>
Lines: 64
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:64430

Hi,

I've been migrating a python2 package+extension to python3. The problem 
I'm running into is with ./configure and which version it picks up or 
doesn't in this case.

The default is python2 and works just fine as expected.

However, when ./configure PYTHON=python3 is run, the problems occur. 
"./configure" picks python3 correctly and propagates that through to all 
of the makefiles created. Good so far. It defines all of the appropriate 
libs and include with the '3.3' extension.

The yum installed python3, however, is denoted by a suffix 'dm', 
yielding an extension of '3.3dm' (Fedora 20)
Building and installing from source, python has a suffix 'm', so the 
extension is '3.3m;

In ./configure, PYTHON_VERSION is set by "$PYTHON -c 'import sys; 
print(sys.version[:3])'" which reports "3.3". PYTHON_VERSION is then 
used as the suffix to find all of the appropriate python directories, 
libraries, site-packages and includes. The same result is had if 
python3.3m or python3.3dm is used.

Unfortunately, this isn't enough, as the python site packages are 
installed with naming ending in 'm' or 'dm', resulting in all of the 
makefiles failing because they can't find the libraries, include files, 
or site packages.

I've kludged a solution by manually creating soft links in the lib and 
include directories which almost solves the problem:

for example in /usr/lib64:

lrwxrwxrwx.  1 root root      19 2013-12-18 15:02 libpython2.7.so -> 
libpython2.7.so.1.0
-r-xr-xr-x.  1 root root 1800480 2013-11-12 08:47 libpython2.7.so.1.0
lrwxrwxrwx   1 root root      21 2014-01-20 16:11 libpython3.3dm.so -> 
libpython3.3dm.so.1.0
-rwxr-xr-x   1 root root 3057640 2013-11-07 02:03 libpython3.3dm.so.1.0
lrwxrwxrwx   1 root root      20 2014-01-20 16:11 libpython3.3m.so -> 
libpython3.3m.so.1.0
-rwxr-xr-x   1 root root 2498992 2013-11-07 02:03 libpython3.3m.so.1.0
lrwxrwxrwx   1 root root      20 2014-01-20 16:37 libpython3.3.so -> 
libpython3.3m.so.1.0
-rwxr-xr-x   1 root root    6704 2013-11-07 02:03 libpython3.so

This approach doesn't feel right to me.  I don't think pythonX.Y-config 
would work either as one would need to know in advance specifically 
which one to call and there'd be extra work to extract the full version 
info, etc. ("$python3-config --includes" yields 
-I/usr/include/python3.3m -I/usr/include/python3.3m)

Has anyone else come up against this? If so, what was the solution?

BTW - anyone know what the 'm' and 'dm' suffixes indicate?

TIA.