So we found another variation between how different distros build
CPython [1], and I'm very confused.
Fedora (for example) turns out to work the way I naively expected:
taking py27 as our example, they have:
- libpython2.7.so.1.0 contains the actual python runtime
- /usr/bin/python2.7 is a tiny (~
> What are Debian/Ubuntu doing in distutils so that extensions don't link
to libpython by default?
I don't know exactly, but one way to reproduce this is simply to build the
interpreter without `--enable-shared`.
I don't know that their reasons are, but I presume that the Debian
maintainers have
On Sun, 7 Feb 2016 00:25:57 -0800
"Robert T. McGibbon" wrote:
> > What are Debian/Ubuntu doing in distutils so that extensions don't link
> to libpython by default?
>
> I don't know exactly, but one way to reproduce this is simply to build the
> interpreter without `--enable-shared`.
See https:/
On 07.02.2016 13:38, Antoine Pitrou wrote:
On Sun, 7 Feb 2016 00:25:57 -0800
"Robert T. McGibbon" wrote:
What are Debian/Ubuntu doing in distutils so that extensions don't link
to libpython by default?
I don't know exactly, but one way to reproduce this is simply to build the
interpreter with
On Sun, Feb 7, 2016 at 4:38 AM, Antoine Pitrou wrote:
> On Sun, 7 Feb 2016 00:25:57 -0800
> "Robert T. McGibbon" wrote:
>> > What are Debian/Ubuntu doing in distutils so that extensions don't link
>> to libpython by default?
>>
>> I don't know exactly, but one way to reproduce this is simply to b
> One option we have then is to remove all DT_NEEDED references to
libpython in manylinux wheels. We get instant compatibility for bare
Debian / Ubuntu Python installs, at the cost of causing some puzzling
crash for the case of: dlopened library with embedded Python
interpreter where the embedded P
On Sun, Feb 7, 2016 at 2:19 PM, Robert T. McGibbon wrote:
>> One option we have then is to remove all DT_NEEDED references to
> libpython in manylinux wheels. We get instant compatibility for bare
> Debian / Ubuntu Python installs, at the cost of causing some puzzling
> crash for the case of: dlop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2016 05:35 AM, Marius Gedminas wrote:
> And people who run build Python 2.7 with './configure && make && make
> install'
>
> Why does upstream Python default to UCS-2 builds on Linux anyway?
I don't recall if it had any bearing on the choic
On 8 February 2016 at 09:07, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/06/2016 05:35 AM, Marius Gedminas wrote:
>
>> And people who run build Python 2.7 with './configure && make && make
>> install'
>>
>> Why does upstream Python default to UCS-2 builds on Linu
On 6 February 2016 at 21:26, Marius Gedminas wrote:
> On Sat, Feb 06, 2016 at 09:18:39PM +1000, Nick Coghlan wrote:
>> On 6 February 2016 at 20:35, Marius Gedminas wrote:
>> > FWIW the rationale Pyenv gave when they rejected a bug asking for UCS-4
>> > builds by default was "we prefer to follow u
On 8 February 2016 at 08:33, Matthew Brett wrote:
> It seems reasonable to build to the same compatibility level as most
> Debian packaged modules.
Right, one of the key things to remember with manylinux1 is that it
is, *quite deliberately*, only an 80% solution to the cross-distro
lack-of-ABI-co
On Sun, Feb 7, 2016 at 7:48 PM, Nick Coghlan wrote:
> On 8 February 2016 at 08:33, Matthew Brett wrote:
>> It seems reasonable to build to the same compatibility level as most
>> Debian packaged modules.
>
> Right, one of the key things to remember with manylinux1 is that it
> is, *quite delibera
On Sun, Feb 7, 2016 at 12:01 AM, Nathaniel Smith wrote:
> 2) if I ever embed cpython by doing dlopen("libpython2.7.so.1"), or
> dlopen("some_plugin_library_linked_to_libpython.so"), then the
> embedded cpython will not be able to load python extensions that are
> compiled in the Debian-style (but
13 matches
Mail list logo
