Anyone have an idea about what the 'm' suffix is on some python libraries? e.g. libpython3.3m.so -Arran
On 07/23/2013 08:52 PM, Arran Cudbard-Bell wrote:
Anyone have an idea about what the 'm' suffix is on some python libraries? e.g. libpython3.3m.so
It signals that it was built with pymalloc. I believe other letters are possible, to indicate other build-time options e.g. debugging compiled in, unicode width. The idea, if I understand it correctly, is to allow more than one installation of the same version of python with these different build-time options, and this is achieved with the namespacing symbol ("m" in this case) IIRC the python binary and all the modules link against the 3.3m.so and the "libpython3.so" is a tiny stub that does nothing. I assume you are using python3-config [--cflags|--libs] to get the various compiler flags back; I guess if you want to permit people to build against >1 installed python, you will want a: --with-pyconfig ...and they can always run: ./configure --with-pyconfig=/usr/bin/python3.3mabceud-config ;o)
On 23 Jul 2013, at 23:04, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 07/23/2013 08:52 PM, Arran Cudbard-Bell wrote:
Anyone have an idea about what the 'm' suffix is on some python libraries? e.g. libpython3.3m.so
It signals that it was built with pymalloc. I believe other letters are possible, to indicate other build-time options e.g. debugging compiled in, unicode width. The idea, if I understand it correctly, is to allow more than one installation of the same version of python with these different build-time options, and this is achieved with the namespacing symbol ("m" in this case)
Ah, thanks. Is this a new thing for python3?
IIRC the python binary and all the modules link against the 3.3m.so and the "libpython3.so" is a tiny stub that does nothing.
I assume you are using python3-config [--cflags|--libs] to get the various compiler flags back; I guess if you want to permit people to build against >1 installed python
The current configure script doesn't. The most advanced it gets is using sys.prefix/exec_prefix/version. Is there a similar utility for python 2.x?
, you will want a:
--with-pyconfig
...and they can always run:
./configure --with-pyconfig=/usr/bin/python3.3mabceud-config
Neat, i'll add that in. As an aside, it looks like the module is not wholly compatible with Python 3, it still builds, but lots of mismatched types and undefined symbols. If anyone wants to have a go at fixing it doesn't look too hard. Most of the issues are in the martialing/un-martialing code. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 24/07/13 10:19, Arran Cudbard-Bell wrote:
On 23 Jul 2013, at 23:04, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 07/23/2013 08:52 PM, Arran Cudbard-Bell wrote:
Anyone have an idea about what the 'm' suffix is on some python libraries? e.g. libpython3.3m.so
It signals that it was built with pymalloc. I believe other letters are possible, to indicate other build-time options e.g. debugging compiled in, unicode width. The idea, if I understand it correctly, is to allow more than one installation of the same version of python with these different build-time options, and this is achieved with the namespacing symbol ("m" in this case)
Ah, thanks. Is this a new thing for python3?
I think so, but I'm not really using py3 much yet.
The current configure script doesn't. The most advanced it gets is using sys.prefix/exec_prefix/version.
Is there a similar utility for python 2.x?
python 2.6 and 2.7 have python-config with the same interface; not sure about 2.5, don't have that installed anywhere. 2.4 definitely does not.
As an aside, it looks like the module is not wholly compatible with Python 3, it still builds, but lots of mismatched types and undefined symbols.
If anyone wants to have a go at fixing it doesn't look too hard. Most of the issues are in the martialing/un-martialing code.
Shudder; C-codebase supporting both py2 and py3 - no, I think I'll pass on that...
On 07/24/2013 05:19 AM, Arran Cudbard-Bell wrote:
As an aside, it looks like the module is not wholly compatible with Python 3, it still builds, but lots of mismatched types and undefined symbols.
If anyone wants to have a go at fixing it doesn't look too hard. Most of the issues are in the martialing/un-martialing code.
Shudder; C-codebase supporting both py2 and py3 - no, I think I'll pass on that...
I have a lot of experience with CPython. One of my upcoming tasks is to convert a C based Python library to support both Py2 and Py3 which will force me to learn the conversion issues. But I won't be getting to that for a month or two. I could probably take a look this issue after I've got some more experience with that. But I don't have time in the immediate near future, so if you can wait I could probably help. FWIW the Py2 migration to Py3 is just starting to get attention in a lot of places, despite Py3 having been out several years most places are still running Py2 so I don't think we've reached a critical need just yet. HTH, -- John
On 24/07/13 13:59, John Dennis wrote:
On 07/24/2013 05:19 AM, Arran Cudbard-Bell wrote:
As an aside, it looks like the module is not wholly compatible with Python 3, it still builds, but lots of mismatched types and undefined symbols.
If anyone wants to have a go at fixing it doesn't look too hard. Most of the issues are in the martialing/un-martialing code.
Shudder; C-codebase supporting both py2 and py3 - no, I think I'll pass on that...
I have a lot of experience with CPython. One of my upcoming tasks is to convert a C based Python library to support both Py2 and Py3 which will force me to learn the conversion issues. But I won't be getting to that for a month or two. I could probably take a look this issue after I've got some more experience with that. But I don't have time in the immediate near future, so if you can wait I could probably help. FWIW the Py2 migration to Py3 is just starting to get attention in a lot of places, despite Py3 having been out several years most places are still running Py2 so I don't think we've reached a critical need just yet.
Well, one option would be to use cython against a small C lib, as cython already generates py2/py3-safe code.
participants (3)
-
Arran Cudbard-Bell -
John Dennis -
Phil Mayers