[issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat (libssl, libcrypto)

Antoine Pitrou report at bugs.python.org
Sun Dec 11 21:02:39 CET 2011


Antoine Pitrou <pitrou at free.fr> added the comment:

> "It doesn't happen in Python 3"
> 
> Yet the cheap/unnecessary pre-imports of ssl in those other mentioned
> socket using libs (urllib (cgi!),httplib,smtplib,pop,imap...) exist
> there. socket is rarely used directly, so not much difference to Py2
> in effect overall.

Well, by this measure, we probably have unnecessary imports all over the
place, since the general guideline is to import modules at the top-level
rather than inside functions (the reason is partly technical, to avoid
potential deadlocks with the import lock).

> Thus I'd request to not close this issue so swift. This is IHMO really
> a point to make python startup significantly faster, with a rather
> simple means.

If you are using a network library such as urllib or others you
mentioned, then startup time will surely be small compared to the time
spent sending and retrieving data over the network, no?

> Also the linkage of _ssl solely against a detailed version of
> libssl/libcrypto is still questionable.

I don't know the reasons (if any). Perhaps you can open a separate issue
about that?

> "This is therefore a problem with the Debian package"
> 
> I'm not into the Python build files. Just to ask/double-check: is that
> observed _semi_ static link selection (which is good otherwise -
> somebody must have done surprisingly lots of care) really from Debian
> or is there maybe a sort of 2nd default option bundle somewhere in
> Pythons configure? (If really not so I would go for Debian BTS.)

Well, seeing as Mageia's Python 2.7 doesn't have the problem, I really
think it must be Debian-specific:

$ ldd /usr/bin/python
	linux-vdso.so.1 =>  (0x00007fff4dd13000)
	libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0
(0x00007f45809ff000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f45807e3000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f4580472000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f458026e000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f458006b000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f457fde9000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4580dc0000)
$ ldd /usr/lib64/libpython2.7.so.1.0
	linux-vdso.so.1 =>  (0x00007fffb53ff000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc0d6455000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc0d6251000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007fc0d604d000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fc0d5dcb000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc0d5a5a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc0d6a51000)

Also, I've just compiled a fresh Python 2.6 and I get similar results:

$ ldd ./python
	linux-vdso.so.1 =>  (0x00007fffa9795000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5f76439000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f5f76235000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f5f76032000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f5f75db0000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5f75a3f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5f76655000)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________


More information about the Python-bugs-list mailing list