Symbols files for C++ libraries for Ubuntu main

[Sebastien Bacher]

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/20230609/f1e94e45/attachment.html>