Re: preparing for GCC 5, especially libstdc++6
On 07/02/2015 06:45 PM, Emilio Pozuelo Monfort wrote:
> 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 [1].
>> 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 [2] 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.
agreed. So I think filing these issues as a task to check their libraries is the
right thing to do, and asking to close the issue if the packages should just be
rebuilt without a transition.
> 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.
> Right?
We could do the GCC 5 switch first, but then would have to deal with a second
round of uploads once we change the default ABI. I'd like to avoid that. Note
that for the packages mentioned in the transition we have far more RC issues
which are unrelated to GCC 5. From my point the GCC 5 issues can be handled,
and I'm currently asking people to help with fixes. I'm unsure what to do with
all the other RC issues, as these are popping up while other unrelated packages
are uploaded to the archive. Maybe let auto removals do it's work?
>> 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
> mind. :)
Now filed as
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org
Matthias
Reply to: