[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#791157: marked as done (libproxy: library transition may be needed when GCC 5 is the default)

Your message dated Wed, 12 Aug 2015 14:17:38 +0200
with message-id <20150812121738.GA9784@dogguy.org>
and subject line Re: Bug#791157: libproxy: library transition may be needed when GCC 5 is the default
has caused the Debian Bug report #791157,
regarding libproxy: library transition may be needed when GCC 5 is the default
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
791157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791157
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: src:libproxy
Version: 0.4.11-4
Severity: important
Tags: sid stretch
User: debian-gcc@lists.debian.org
Usertags: libstdc++-cxx11

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,
and 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.

What is needed:

 - Rebuild the library using g++/g++-5 from experimental. Note that
   most likely all C++ libraries within the build dependencies need
   a rebuild too. You can find the log for a rebuild in
     https://people.debian.org/~doko/logs/gcc5-20150701/
   Search for "BEGIN GCC CXX11" in the log.

 - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
   library API, and are used by the reverse dependencies of the
   library.

 - If there are no symbols matching __cxx11 or B5cxx11 in the symbols
   forming the library API, you should close this issue with a short
   explanation.
 
 - If there are no reverse dependencies, it should be the package
   maintainers decision if a transition is needed.  However this might
   break software which is not in the Debian archive, and built
   against these packages.

 - If a library transition is needed, please prepare for the change.
   Rename the library package, append "v5" to the name of the package
   (e.g. libfoo2 -> libfoo2v5). Such a change can be avoided, if you
   have a soversion bump and you upload this version instead of the
   renamed package.  Prepare a patch and attach it to this issue (mark
   this issue with patch), so that it is possible to NMU such a
   package. We'll probably have more than hundred transitions
   triggered. Then reassign the issue to release.debian.org and
   properly tag it as a transition issue, by sending an email to
   control@bugs.debian.org:
   
     user release.debian.org@packages.debian.org
     usertag <this issue> + transition
     block <this issue> by 790756
     reassign <this issue> release.debian.org
   
 - If unsure if a transition is needed, please tag the issue with help
   to ask for feedback from other Debian developers.

The libstdc++6 transition will be a large one, and it will come with a
lot of pain.  Please help it by preparing the follow-up transitions.

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition

--- End Message ---
--- Begin Message --- 
On Fri, Jul 31, 2015 at 12:42:55PM +0100, Iain Lane <laney@debian.org> wrote:
> I think that one is required. Seems that some symbols use
> std::basic_string, e.g.
> 
>   libproxy::url::url(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
> 

I don't think this one is required because almost nothing is exposed in the
API of libproxy. A rebuild might be needed but no package renaming is needed.
In addition to that, it seems to be a C interface so I don't think we should
care about this one. I'd close this bug.

Feel free to reopen it if I am mistaken.

Regards,

-- 
Mehdi Dogguy

--- End Message ---
Reply to: