Package: python2.7-dev
Version: 2.7.3-6
Severity: important
Dear Maintainer,
I've noticed that the python2.7-dev package is quite a bit bigger than
it would really need to be for most uses; in particular, on my i386
machine I have:
,----[ ls -l /usr/lib/python2.7/config/libpython*.a ]
| -rw-r--r-- 1 root root 14279960 Jan 2 12:47
/usr/lib/python2.7/config/libpython2.7-pic.a
| -rw-r--r-- 1 root root 13980424 Jan 2 12:47
/usr/lib/python2.7/config/libpython2.7.a
`----
It turns out that the reason these files are so big is that they've
got GIMPLE code in them, from using -flto to compile Python, as can be
seen from all the sections starting with ".gnu.lto_" listed in the
output of:
$ size -A /usr/lib/python2.7/config/libpython*.a
It shouldn't be very surprising that GIMPLE doesn't have a stable
format, given especially if you know what GCC does to make precompiled
headers (it essentially reads in the header and then dumps it's memory
to disk). More surprisingly, though, GCC *does not know* when the
GIMPLE is in an incompatible format (see the included IRC conversation
from #gcc), even when this is caused by flags passed in at link-time.
So, attempts to use the static libraries from this package and -flto
(even if LTO is only wanted within a given application, not between it
and libpython) can do several different things:
1. Work: if a "close enough" compiler build is used, and the flags
passed to gcc for linking are compatible with those used when
python was compiled, this could actually work
2. Fail: otherwise, it will fail, either
a) Loudly: most of the time, it will notice that something is
wrong (but not what) and produce an Internal Compiler Error
or
b) Silently: if you'ru unlucky, it could not notice and just
produce wrong code.
So basically, it looks like you need to do one of:
1. Strip out all sections with prefix ".gnu.lto_"
2. Drop these libraries
3. As a last resort, prominently document that -flto shouldn't be used
when linking with these libraries
I couldn't figure out how to do #1, but Jakub Wilk told me to let you
worry about that. (And now that I think on it, I remember that you are
or include doko so *of course* you can figure it out better than I can ;-)
<SamB> How stable is the GIMPLE representation used in lto? That is, how often
does compatibility tend to break?
<f9> all the time
<f9> but mostly it's the options, but other things do too
<SamB> So is it silly to include it in, say, the static libraries in Debian's
python2.7-dev package?
* jamespat has quit (Remote host closed the connection)
<SamB> you don't know?
<dnovillo> SamB: not silly. unadvisable.
<SamB> I'm not sure what distinction you're trying to make
* afenkart has quit (Ping timeout: 480 seconds)
<mhargett> SamB: in the case where you're using the distro compiler only, it
may be okay
<mhargett> but it turns into kind of a support nightmare, I would think
<dnovillo> you may get lucky with it, but we currently do not try to maintain
any guarantees even within the same release.
<f9> only if the distribution never changes anything in their compiler
<dnovillo> As f9 said,even using different flags may result in different
bytecodes
<SamB> oh, these flags are to GCC's ./configure ?
<f9> dnovillo: I meant adding a new flag to compiler always renumbers
<dnovillo> that too.
* silver24k1 has quit (Ping timeout: 480 seconds)
<dnovillo> SamB: to the application. if the bytecodes you have were produced
with gcc -flto -O0. there is no guarantee that they will work with gcc -flto
-O1.
<SamB> what happens when it breaks?
<SamB> can GCC tell and just fall back to the already-compiled code, or just
screw up?
<mhargett> SamB: gosh, that would be nice.
<f9> samB: internal errors normally
<SamB> can I paste this conversation in the bug report I'm writing?
<dnovillo> SamB: we have some consistency checks, but they are weak.
<dnovillo> SamB: yes, of course.
<SamB> thanks!
-- System Information:
Debian Release: 7.0
APT prefers testing-proposed-updates
APT policy: (991, 'testing-proposed-updates'), (990, 'testing'), (500,
'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages python2.7-dev depends on:
ii libexpat1-dev 2.1.0-1
ii libpython2.7 2.7.3-6
ii libssl-dev 1.0.1c-4
ii python2.7 2.7.3-6
Versions of packages python2.7-dev recommends:
ii libc6-dev [libc-dev] 2.13-37
python2.7-dev suggests no packages.
-- no debconf information
--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
