Symbols files for C++ libraries for Ubuntu main

[Sebastien Bacher]

And I just noticed that Lunar SRU
https://launchpad.net/ubuntu/+source/libcupsfilters/2.0~rc1-0ubuntu1.2

Which is another variant of the problems described before. gcc 12.3 is 
being SRUed o Lunar and according to the report linked to that update

 > The added symbols don't belong to the ABI, however the build fails 
because dh_makeshlibs is called with -c4, and two more template 
instantiations show up on riscv64.

So we end up in a situation where issuing a minor gcc update is leading 
to build failures for our packages...

Cheers,
Sébastien


Le 09/06/2023 à 14:27, Sebastien Bacher a écrit :
>
> Hey there,
>
> We had been struggling with a few of those cases recently in desktop 
> and I was going to send an email about the topic then checking the 
> archive I found back that discussion that I had forgotten about.
>
> I would like to ask if there is any chance the MIR team would 
> reconsider their position on the topic (at least until the day we have 
> a somewhat working solution we can use)?
>
>
> Here is why. Taking  a recent example from desktop and describing the 
> experience on one package where we basically had to go through those steps
>
> 1. We added a symbols to libcupsfilters as part of the MIR promotion
> https://git.launchpad.net/ubuntu/+source/libcupsfilters/commit/debian/libcupsfilters2.symbols?h=applied/ubuntu/devel&id=c5821fe0
>
> The build failed on armhf because dh_makeshlibs report symbols on 
> armhf which do not existing on amd64
> https://launchpadlibrarian.net/647850924/buildlog_ubuntu-lunar-armhf.libcupsfilters_2.0~b2-0ubuntu4_BUILDING.txt.gz
>
> which also included those types of changes
>
> - _Znam at Base 2.0~b2-0ubuntu3
> + _Znaj at Base 2.0~b2-0ubuntu4
> +#MISSING: 2.0~b2-0ubuntu4# _Znam at Base 2.0~b2-0ubuntu3
>
> I personally don't understand why we have those symbols existing on 
> armhf which don't exist on amd64. Nor why _Znam at Base is becoming 
> _Znaj at Base nor how we are supposed to handle such cases
>
> 2. I tried to help getting that resolved with that upload
> http://launchpadlibrarian.net/647856580/libcupsfilters_2.0~b2-0ubuntu4_2.0~b2-0ubuntu5.diff.gz
>
> Which basically add the symbols showing a new on the armhf as 
> '(optional)' and also listed those that changes as optional in their 
> different variants
>
> 3. similar round for riscv64
>
> http://launchpadlibrarian.net/647865001/libcupsfilters_2.0~b2-0ubuntu5_2.0~b2-0ubuntu6.diff.gz
>
> 4. doing those tweaks need to be done manually since it's not only 
> applying the diff but also adding optional keyword at places, I got 
> one wrong and it failed to build again
>
> add one more symbol specific to risvc
> http://launchpadlibrarian.net/647875197/libcupsfilters_2.0~b2-0ubuntu6_2.0~b2-0ubuntu7.diff.gz
>
> 5. still failed, I had to add another bunch of symbols from the 
> previous build log
>
> http://launchpadlibrarian.net/647896999/libcupsfilters_2.0~b2-0ubuntu7_2.0~b2-0ubuntu8.diff.gz
>
> Which finally got us a working build.
>
>
> I understand the motivation for wanting a symbol file but I agree with 
> what Robie, what's the benefit. In that case we spent a few hours to 
> end up with a .symbols which as over 150 '(optional)' entries, that 
> doesn't protect us much better than just not having a .symbols or 
> using -c0 but still has a high cost.
> And from experience it is likely that following the next toolchain 
> update the .symbols will not match anymore and that those of us who 
> will end up having to fix the package build will not understand why 
> and just end up applying the diff proposed by dpkg-gensymbols.
>
> Checking on the Debian side, https://wiki.debian.org/UsingSymbolsFiles 
> has a 'C++ libraries' section which start by this statement written in 
> bold style
>
> > For C++ libraries it is often better not to ship symbols files.
>
> Which means we will often fail at upstreaming such improvements to 
> Debian and will have to increase our delta. And I don't blame them, 
> I'm not even sure how to deal with the 'the symbols change between 
> architectures' out of throwing builds to a ppa to get results and 
> iterate and Debian doesn't have the ppa option...
>
> Cheers,
> Sebastien Bacher
>
> Le 22/05/2018 à 18:25, Robie Basak a écrit :
>> On Fri, May 18, 2018 at 08:29:13PM +0200, Matthias Klose wrote:
>>> I completely disagree.  Replacing a somehow suboptimal check with no
>>> check is not an option.
>> On Fri, May 18, 2018 at 08:22:55PM +0100, Dimitri John Ledkov wrote:
>>> IMHO symbols files should be mandatory for any new libraries
>>> introduced in the archive.
>>>
>>> And we should assert symbols files for everything in main, and fix all
>>> the things.
>>>
>>> It's 2018, and we really ought to have sensible and strict symbols
>>> files.
>> Both of these statements on their own state that we must do this work
>> but don't explain why this is of benefit to Ubuntu. I feel that you need
>> to justify your position rather than just stating it.
>>
>> Can you provide examples of where maintaining this delta has actually
>> helped make Ubuntu better, in the specific case that C++ symbols are
>> being maintained by Ubuntu in a delta that Debian and upstream have
>> declined to adopt or postponed adopting? Without examples, we're not
>> really in a position to assess the trade-off of extra work vs. benefit
>> to Ubuntu. I don't think we should be maintaining delta unless the
>> benefit can be articulated and justified.
>>
>> Separately, I question whether it's in the interest of our project to
>> spend time on maintaining a quality improvement indefinitely if Debian
>> and/or upstream decline to take it, and if that particular improvement
>> is not a high level goal of our project.
>>
>> Thanks,
>>
>> Robie
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20230629/f8aaf310/attachment.html>