[Python-Dev] issue 9807 - a glitch in coexisting builds of different types

Barry Warsaw barry at python.org
Mon Oct 4 20:34:22 CEST 2010


On Oct 02, 2010, at 04:50 PM, Nick Coghlan wrote:

>On Sat, Oct 2, 2010 at 10:24 AM, Antoine Pitrou <solipsis at pitrou.net>
>wrote:
>> On Fri, 1 Oct 2010 20:06:57 -0400
>> Barry Warsaw <barry at python.org> wrote:
>>>
>>> With my branch, you'll end up with this in /tmp/python:
>>>
>>>     bin/python3.2m   - the normal build binary
>>>     bin/python3.2dmu - the wide+pydebug build binary
>>>     bin/python3.2m-config
>>>     bin/python3.2dmu-config
>>
>> Do users really want to see such idiosyncratic suffixes?
>
>Ordinary users won't be building Python from source. Developers won't
>care so long as we clearly document the sundry suffixes and describe
>them in the README (or in a PEP, with a pointer from the README).

I agree with this.

>>>     lib/libpython3.2.so.1.0.m
>>>     lib/libpython3.2.so.1.0.dmum
>>
>> Ditto here. This seems to break well-known conventions.
>> If I look at /usr/lib{,64} on my machine, I can't see a single
>> shared libary file that ends neither in ".so" nor ".so.<some
>> digits>".
>
>Having some characters on the end to flag different kinds of custom
>build seems like it fits within the .so naming conventions I'm aware
>of, but I'm sure the *nix packaging folks will pipe up if Barry starts
>wandering too far afield in this area.

Because -Wl,-h is used, the right soname will get compiled in, so it will
generally just DTRT.  The situation where it can break is if you are not using
distutils to build things.  However, in that case, the symlinks added by 'make
install' should still make things just work.  However, if you don't use
distutils and still want to link against the correct shared library on a
multi-build system, you'll have to modify your rules to grab the build flags
from the Makefile (the easiest route being via sysconfig).

>> Before trying to find a solution to your problem, I think it would be
>> nice to get a consensus that this is really a desired feature.
>
>Having multiple parallel "altinstall" installations be genuinely
>non-interfering out of the box certainly seems like a desirable
>feature to me.

Right.  Isn't that kind of the whole point of altinstall? :)  Well, multiple
coexisting versions of Python, but I think multiple coexisting builds of the
same Python version falls into the same category.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101004/f6422704/attachment.pgp>


More information about the Python-Dev mailing list