[prev in list] [next in list] [prev in thread] [next in thread]
List: ubuntu-devel
Subject: Re: Symbols files for C++ libraries for Ubuntu main
From: Sebastien Bacher <seb128 () ubuntu ! com>
Date: 2023-06-29 13:34:33
Message-ID: 7b635010-755f-09d5-9799-8a76a69382a2 () ubuntu ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@Base 2.0~b2-0ubuntu3
> + _Znaj@Base 2.0~b2-0ubuntu4
> +#MISSING: 2.0~b2-0ubuntu4# _Znam@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@Base is becoming
> _Znaj@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
> >
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>And I just noticed that Lunar SRU <br>
<a class="moz-txt-link-freetext" \
href="https://launchpad.net/ubuntu/+source/libcupsfilters/2.0~rc1-0ubuntu1.2">https://launchpad.net/ubuntu/+source/libcupsfilters/2.0~rc1-0ubuntu1.2</a><br>
<br>
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</p>
<p>> 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.</p>
<p>So we end up in a situation where issuing a minor gcc update is
leading to build failures for our packages...<br>
<br>
Cheers,<br>
Sébastien<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Le 09/06/2023 à 14:27, Sebastien Bacher
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:67216a04-e786-8780-c237-b6c2e0071d68@ubuntu.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hey there,</p>
<p>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.<br>
</p>
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)?<br>
<p><br>
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</p>
<p>1. We added a symbols to libcupsfilters as part of the MIR
promotion<br>
<a class="moz-txt-link-freetext"
href="https://git.launchpad.net/ubuntu/+source/libcupsfilters/commit/debian/libcupsfilters2.symbols?h=applied/ubuntu/devel&id=c5821fe0"
moz-do-not-send="true">https://git.launchpad.net/ubuntu/+source/libcupsfilters/commit/debian/libcupsfilters2.symbols?h=applied/ubuntu/devel&id=c5821fe0</a></p>
<p>The build failed on armhf because dh_makeshlibs report symbols
on armhf which do not existing on amd64<br>
<a class="moz-txt-link-freetext"
href="https://launchpadlibrarian.net/647850924/buildlog_ubuntu-lunar-armhf.libcupsfilters_2.0~b2-0ubuntu4_BUILDING.txt.gz"
moz-do-not-send="true">https://launchpadlibrarian.net/647850924/buildlog_ubuntu-lunar-armhf.libcupsfilters_2.0~b2-0ubuntu4_BUILDING.txt.gz</a><br>
<br>
which also included those types of changes<br>
</p>
<pre>- _Znam@Base 2.0~b2-0ubuntu3
+ _Znaj@Base 2.0~b2-0ubuntu4
+#MISSING: 2.0~b2-0ubuntu4# _Znam@Base 2.0~b2-0ubuntu3
</pre>
<p>I personally don't understand why we have those symbols
existing on armhf which don't exist on amd64. Nor why _Znam@Base
is becoming _Znaj@Base nor how we are supposed to handle such
cases<br>
<br>
2. I tried to help getting that resolved with that upload<br>
<a class="moz-txt-link-freetext"
href="http://launchpadlibrarian.net/647856580/libcupsfilters_2.0~b2-0ubuntu4_2.0~b2-0ubuntu5.diff.gz"
moz-do-not-send="true">http://launchpadlibrarian.net/647856580/libcupsfilters_2.0~b2-0ubuntu4_2.0~b2-0ubuntu5.diff.gz</a></p>
<p>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<br>
</p>
<p>3. similar round for riscv64</p>
<p><a class="moz-txt-link-freetext"
href="http://launchpadlibrarian.net/647865001/libcupsfilters_2.0~b2-0ubuntu5_2.0~b2-0ubuntu6.diff.gz"
moz-do-not-send="true">http://launchpadlibrarian.net/647865001/libcupsfilters_2.0~b2-0ubuntu5_2.0~b2-0ubuntu6.diff.gz</a></p>
<p>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</p>
<p>add one more symbol specific to risvc<br>
<a class="moz-txt-link-freetext"
href="http://launchpadlibrarian.net/647875197/libcupsfilters_2.0~b2-0ubuntu6_2.0~b2-0ubuntu7.diff.gz"
moz-do-not-send="true">http://launchpadlibrarian.net/647875197/libcupsfilters_2.0~b2-0ubuntu6_2.0~b2-0ubuntu7.diff.gz</a></p>
<p>5. still failed, I had to add another bunch of symbols from the
previous build log<br>
<br>
<a class="moz-txt-link-freetext"
href="http://launchpadlibrarian.net/647896999/libcupsfilters_2.0~b2-0ubuntu7_2.0~b2-0ubuntu8.diff.gz"
moz-do-not-send="true">http://launchpadlibrarian.net/647896999/libcupsfilters_2.0~b2-0ubuntu7_2.0~b2-0ubuntu8.diff.gz</a></p>
<p>Which finally got us a working build.</p>
<p><br>
</p>
<p>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. <br>
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.</p>
<p>Checking on the Debian side, <a class="moz-txt-link-freetext"
href="https://wiki.debian.org/UsingSymbolsFiles"
moz-do-not-send="true">https://wiki.debian.org/UsingSymbolsFiles</a>
has a 'C++ libraries' section which start by this statement
written in bold style<br>
<br>
> For C++ libraries it is often better not to ship symbols
files. <br>
</p>
<p>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...<br>
<br>
Cheers,<br>
Sebastien Bacher<br>
</p>
<div class="moz-cite-prefix">Le 22/05/2018 à 18:25, Robie Basak a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20180522162522.GE18577@mal.justgohome.co.uk">
<pre class="moz-quote-pre" wrap="">On Fri, May 18, 2018 at 08:29:13PM +0200, \
Matthias Klose wrote: </pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I completely disagree. Replacing a \
somehow suboptimal check with no check is not an option.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">On Fri, May 18, 2018 at 08:22:55PM +0100, \
Dimitri John Ledkov wrote: </pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</blockquote>
</body>
</html>
[Attachment #6 (text/plain)]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic