On Sat, 15 Aug 2015 at 00:56:23 +0200, Tzafrir Cohen wrote:
> Now to the likes of:
>
> - _ZN2pj10StreamInfoD1Ev@Base 2.4~dfsg
> - _ZN2pj10StreamInfoD2Ev@Base 2.4~dfsg
>
> This is originally:
>
> pjsip/include/pjsua2/call.hpp:struct StreamInfo
>
> I see that many structs defined in pjsua2 created constructors and now
> they don't.
These are actually destructors, as you can tell by piping that text
through c++filt:
> - pj::StreamInfo::~StreamInfo()@Base 2.4~dfsg
> - pj::StreamInfo::~StreamInfo()@Base 2.4~dfsg
I believe this is an optimization in g++-5: destructors that
would never be called are not emitted (or something). My understanding
is that these can be deleted from the symbols file.
> -
> _ZN2pj15writeSipHeadersERNS_13ContainerNodeERKSsRKSt6vectorINS_9SipHeaderESaIS5_EE@Base
> 2.4~dfsg
> +
> _ZN2pj15writeSipHeadersERNS_13ContainerNodeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorINS_9SipHeaderESaISB_EE@Base
> 2.4.5~dfsg-1
>
> Seems to be a C++11 issue.
This indicates that pjproject needs to go through the libstdc++ "v5"
transition. Copying text from some of the many bugs I opened about
these over the last month:
Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI. Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols. If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.
In the case of pjproject, those functions look like they might be
public API, so it seems likely that a transition is needed.
The transition normally consists of renaming each
affected library package, adding a v5 suffix (libpj2v5 and so on).
The SONAME should not be changed when doing this.
These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.
Looking at pjproject's build-dependencies, I don't see any C++, so this
sub-transition should be ready to go.
I think 2-day NMU delay is still in effect, although I suspect everyone
who has been NMU'ing for this transition is getting quite burned-out by
this point.
Regards,
S
