Re: preparing for GCC 5, especially libstdc++6
On 07/03/2015 03:24 PM, Matthias Klose wrote:
> 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
while fixing build failures, I set some of these issues to 'confirmed' where I
found link errors while trying to build a package without first rebuilding all
it's c++ dependencies. There are some ... plus there are some more, which I
didn't find while inspecting the libraries. The ones I found were tagcoll, and
exiv2 not showing up in my initial batch, but were tagcoll and exiv2 symbols
from the template headers were included in another library libfoo, and then
trying to build something depending on libfoo failed without rebuilding that libfoo.
So what do we want to do about the default action (always rename, or keep the
name)? Certainly some things will break if you don't rename, however you could
rename the library later too once you see the actual breakage.
Another way to reduce renamings would be to only rename the lowest library in a
library stack (e.g. tagcall in tagcall/libept/wibble/..., glibmm in
glibmm/gtkmm/pangomm/cairomm/...), because almost everything depends on the low
level dependency as well. Not sure how many more stacks we would have.
Matthias
Reply to: