Package: kdevelop Version: 4:4.3.1-3+b1 Followup-For: Bug #707215 The solution to this bug is indeed to rebuild kdevelop, as this bug is caused by a bug in g++ 4.7.0 and 4.7.1 that caused ABI changes in returning std::pairs (see http://gcc.gnu.org/gcc-4.7/changes.html).
The solution is to recompile kdevelop against any libstdc++ except for 4.7.0 or 4.7.1. The problem in this case is related to std::pair<bool, std::size_t> std::__detail::_Prime_rehash_policy::_M_need_rehash (std::size_t, std::size_t, std::size_t, std::size_t); declared in /usr/include/c++/4.7/bits/hashtable_policy.h Until g++ 4.8, this function is defined as inline function in that file. This might seem to protect from ABI problems, but in fact, it does not. This is because the compiler decides the function is too complicated to be inlined, so a compiled version of that function is emitted in every object file calling that function. The emitted function in a certain object is always compatible to the ABI used in that object, but as soon as you link multiple of these objects together, they share using only one function, and all others get discarded (on static linking with ld) or ignored (on dynamic linking). As long as all objects linked together use the same ABI (either the "broken" 4.7.0/4.7.1 ABI or the "correct" ABI), no problem arises. As soon as you link code using the "broken" and the "correct" ABI, a disaster happens. While kdevelop itself is currently compiled against the "broken" ABI, so it does not contain any copies of that function using the "correct" ABI, it is supposed to work. That is until g++ 4.8 (and its accompanying libstdc++). Because that function was emitted out-of-line anyway, the libstdc++ developers decided it makes no sense to emit it in every program and changed it from being inline into being a normal non-inline function with its implementation in libstdc++. The result is a libstdc++ containing one central implementation of that function, of course using the "correct" ABI, as it is not compiled by g++ 4.7.0 or g++ 4.7.1. Every program that loads libstdc++ (that is, every dynmaically compiled C++ program) thus includes the "correct" function. If the first shared object using that function gets loaded after libstdc++, the central version with the "correct" ABI is used, and the local version with the "broken" ABI is ignored, breaking that shared object. This is why libstdc++6 created from g++ 4.8 breaks kdevelop. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (510, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10.0-rc4+ (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kdevelop depends on: ii kde-runtime 4:4.8.4-2 ii kdevelop-data 4:4.3.1-3 ii kdevplatform5-libs 1.3.1-2 ii libc6 2.17-3 ii libgcc1 1:4.8.0-7 ii libkasten1controllers1 4:4.8.4+dfsg-1 ii libkasten1core1 4:4.8.4+dfsg-1 ii libkasten1okteta1controllers1 4:4.8.4+dfsg-1 ii libkasten1okteta1core1 4:4.8.4+dfsg-1 ii libkasten1okteta1gui1 4:4.8.4+dfsg-1 ii libkcmutils4 4:4.8.4-4 ii libkdecore5 4:4.8.4-4 ii libkdeui5 4:4.8.4-4 ii libkio5 4:4.8.4-4 ii libkparts4 4:4.8.4-4 ii libktexteditor4 4:4.8.4-4 ii libplasma3 4:4.8.4-4 ii libprocessui4a 4:4.8.4-6 ii libqt4-dbus 4:4.8.4+dfsg-4 ii libqt4-help 4:4.8.4+dfsg-4 ii libqt4-network 4:4.8.4+dfsg-4 ii libqt4-script 4:4.8.4+dfsg-4 ii libqtcore4 4:4.8.4+dfsg-4 ii libqtgui4 4:4.8.4+dfsg-4 ii libqtwebkit4 2.2.1-5 ii libstdc++6 4.8.0-7 ii libsublime5 1.3.1-2 ii libthreadweaver4 4:4.8.4-4 Versions of packages kdevelop recommends: ii g++ 4:4.7.2-1 ii gcc 4:4.7.2-1 ii gdb 7.4.1+dfsg-0.1 ii make 3.81-8.2 Versions of packages kdevelop suggests: ii cmake 2.8.11-2 pn kapptemplate <none> pn kdevelop-l10n <none> -- no debconf information -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130615170408.21019.85312.reportbug@localhost.localdomain
