Re: preparing for GCC 5, especially libstdc++6
On 01/07/15 14:39, Matthias Klose wrote:
> On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote:
>> On 25/06/15 17:44, Matthias Klose wrote:
>>> On 06/25/2015 01:20 PM, Matthias Klose wrote:
>>>> On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote:
>>>>> - You suggest that some libraries may need to be renamed due to the ABI breaks.
>>>>> Do you have a list of affected libraries?
>>>> No. Getting this list is a bit difficult. Candidates for these packages are the
>>>> GCC 5 build failures due to mismatched symbols files. However there may be more
>>>> packages which successfully build, but have additional symbols (this may be an
>>>> empty set, because usually some symbol names should be just replaced by new ones).
>>> If symbol versioning is used in a library, you probably won't see this at all,
>>> until the package is built using GCC 5. I'll ask for another test rebuild with a
>>> diverted dpkg-gensymbols to look at the generated symbols files.
>> Thanks Matthias. I'd be very interested in knowing more about what breaks.
> We have 361 C++ libraries which define at least one of these new symbols .
> Note this list only includes the packages which succeed to build with GCC 5.
> Another 70 packages might need the same action (the issues at  with severity
> important, which fail during the dpkg-gensymbols call).
> So my proposal would be to file bug reports for each of these packages, asking
> the maintainers for what to do with this library. Actions could be:
> - do nothing, if none of these symbols are part of the library ABI. That
> would be a rebuild of the library and its reverse dependencies.
> - add breaks to all reverse dependencies on this library, and rebuild
> the library and the reverse dependencies.
> - rename the library package and rebuild all reverse dependencies.
> The default action should be the most conservative action (the renaming of the
> library package).
But let's not do transitions unnecessarily... we have hundreds of libraries
there, so if we can avoid a bunch, then we should avoid them. So I'd say the
default action should be to investigate if a transition is needed or not. I'm
not advocating to blindly ignore the problem, fwiw, just want to try to make
this a little manageable.
I see there are quite a few FTBFS bugs for the affected libraries, but since the
plan is to do the switch to GCC 5 first, and the libstdc++6 transition later,
there would be time in between to fix those bugs and prepare for the transition.
> These bug reports could be used as transition bug reports as well, once GCC 5 is
> the default. Then these could be reassigned to release.debian.org once the
> transitions start.
Yeah, that or new bugs. As long as usertags / titles are set properly, I don't