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
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)
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 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:
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 differently,
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.
