Ronald Oussoren wrote:
> My explanation seems to be bad, I meant to say sharing extensions across
> different builds of the same Python version. One might install a normal
> unix build in /opt/python and a framework build in /Library/Frameworks.
Sorry, I didn't read your message carefully enough.
On Feb 8, 2006, at 11:02 AM, Ronald Oussoren wrote:
>
> On 8-feb-2006, at 19:55, Martin v. Löwis wrote:
>
>> Gustavo J. A. M. Carneiro wrote:
>>> Any thoughts? Should I go ahead and open a bug report (maybe with
>>> patch), or is this controversial?
>>
>> I can accept that the Mac does it diff
On 8-feb-2006, at 19:55, Martin v. Löwis wrote:
Gustavo J. A. M. Carneiro wrote:
Any thoughts? Should I go ahead and open a bug report (maybe with
patch), or is this controversial?
I can accept that the Mac does it differently, although I think the
rationale for doing that is dangerous: y
Gustavo J. A. M. Carneiro wrote:
> Any thoughts? Should I go ahead and open a bug report (maybe with
> patch), or is this controversial?
You should only link with libpython if there really is a shared
libpython. In a standard Python installation, there is no libpython, but
instead, symbols are
On 8-feb-2006, at 16:47, Gustavo J. A. M. Carneiro wrote:
gjc:/usr/lib/python2.4/lib-dynload$ ldd itertools.so
libpthread.so.0 => /lib/libpthread.so.0 (0x2abcc000)
libc.so.6 => /lib/libc.so.6 (0x2ace2000)
/lib/ld-linux-x86-64.so.2 (0x4000)
gjc
gjc:/usr/lib/python2.4/lib-dynload$ ldd itertools.so
libpthread.so.0 => /lib/libpthread.so.0 (0x2abcc000)
libc.so.6 => /lib/libc.so.6 (0x2ace2000)
/lib/ld-linux-x86-64.so.2 (0x4000)
gjc:/usr/lib/python2.4/lib-dynload$
It seems that Python C exten
