From: Alastair McKinstry <mckinstry@debian.org>
To: Jakub Jelinek <jakub@redhat.com>, Andreas Schwab <schwab@linux-m68k.org>
Cc: Thomas Koenig <tkoenig@netcologne.de>,
Segher Boessenkool <segher@kernel.crashing.org>,
gcc@gcc.gnu.org, Jonathan Wakely <jwakely@redhat.com>,
fortran@gcc.gnu.org, Tobias Burnus <tobias@codesourcery.com>
Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
Date: Thu, 7 Oct 2021 13:43:47 +0100 [thread overview]
Message-ID: <2b7ce26b-0340-c1d8-8079-64f0a1d46bcd@debian.org> (raw)
In-Reply-To: <20211007100112.GS304296@tucnak>
On 07/10/2021 11:01, Jakub Jelinek wrote:
> On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
>> On Okt 07 2021, Alastair McKinstry wrote:
>>
>>> I strongly advise against this -- identical SONAMEs for the libraries on
>>> all architectures is a key assumption on all Debian-based distributions
>>> and designs
>> Even glibc has differing sonames on some architectures. And libgcc_s,
>> too.
> Yeah, lib[cm].so.6 on most arches and lib[cm].so.6.1 on ia64 or alpha.
> At least on Fedora I don't see a problem having libgfortran.so.5 on
> most arches and libgfortran.so.6 on ppc64le. And then next year or two/3
> switch to libgfortran.so.7 everywhere.
SOVERSION (Major release) (and hence SONAME) change tracking are key to
tracking the task of rebuilds/porting when incompatible changes happen
in libraries
(see https://release.debian.org/transitions/ and
https://wiki.debian.org/Teams/ReleaseTeam/Transitions for examples of
the process).
lib[cm] on ia64 and alpha work in that libc has not changed major
version in many years, and neither ia64 or alpha are currently "release
candidates" in Debian, which we need to keep rebuilds in sync. Even so,
the exception handling needed for them is a wart seen across the distro
dependency trees.
To make upgrades work, we have policy that it's possible that two
versions of a library with different SONAME can co-exist on a users'
system (package libgfortran5 "just" ships the libgfortran.so.5 file,
libgfortran6 can co-exist with it), but a given source package only
provides one of these library packages, and there is only one -dev
package (eg libgfortran-dev pointing libgfortran.so -> libgfortan.so.6).
A transition (eg gcc-11 to gcc-12 moving into the 'testing' staging
distro) updates libgfortran-dev to point to 6, drops libgfortran5 from
the Debian archive (but doesn't delete the package libgfortran5 from the
users' computer) and we rebuild and transition simultaneously all
packages that depend on libgfortran5.
So if we introduce libgfortran6 for ppc64le (with potential ABI changes
such as KIND) we rely on libgfortran5 disappearing for our transition
scripts to work, and testing the transition process. We can special-case
it just for one arch/package but its significant work and really painful.
A simple soname/soversion transition across all archs is much preferred.
> Jakub
Alastair
--
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
next prev parent reply other threads:[~2021-10-07 12:43 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 10:07 Jakub Jelinek
2021-10-04 11:24 ` Richard Biener
2021-10-04 11:36 ` Jakub Jelinek
2021-10-04 12:31 ` Jakub Jelinek
2021-10-04 14:14 ` Jakub Jelinek
2021-10-04 16:47 ` Joseph Myers
2021-10-04 18:33 ` Segher Boessenkool
2021-10-04 19:24 ` Joseph Myers
2021-10-05 17:43 ` Segher Boessenkool
2021-10-14 19:39 ` Bill Schmidt
2021-10-15 0:26 ` Segher Boessenkool
2021-10-05 20:16 ` Thomas Koenig
2021-10-05 21:54 ` Segher Boessenkool
2021-10-06 6:59 ` Thomas Koenig
2021-10-06 15:17 ` Segher Boessenkool
2021-10-06 15:41 ` Jakub Jelinek
2021-10-06 16:07 ` Segher Boessenkool
2021-10-06 16:34 ` Jakub Jelinek
2021-10-06 16:59 ` Segher Boessenkool
2021-10-06 17:07 ` Jakub Jelinek
2021-10-06 17:50 ` Segher Boessenkool
2021-10-06 19:30 ` Peter Bergner
2021-10-06 17:13 ` Joseph Myers
2021-10-06 18:39 ` Segher Boessenkool
2021-10-06 19:42 ` Joseph Myers
2021-10-06 20:57 ` Segher Boessenkool
2021-10-06 21:55 ` Joseph Myers
2021-10-06 22:03 ` Joseph Myers
2021-10-08 17:53 ` Segher Boessenkool
2021-10-11 20:11 ` Joseph Myers
2021-10-15 0:16 ` Segher Boessenkool
2021-10-06 15:42 ` David Edelsohn
2021-10-06 16:19 ` Segher Boessenkool
2021-10-06 17:38 ` David Edelsohn
2021-10-07 3:42 ` Michael Meissner
2021-10-08 21:10 ` Segher Boessenkool
2021-10-07 9:48 ` Alastair McKinstry
2021-10-07 9:56 ` Andreas Schwab
2021-10-07 10:01 ` Jakub Jelinek
2021-10-07 12:43 ` Alastair McKinstry [this message]
2021-10-05 21:53 ` Jonathan Wakely
2021-10-07 3:35 ` Michael Meissner
2021-10-07 6:08 ` Thomas Koenig
2021-10-07 9:40 ` Jakub Jelinek
2021-10-07 15:24 ` Michael Meissner
2021-10-07 15:33 ` Jakub Jelinek
2021-10-08 6:35 ` Thomas Koenig
2021-10-08 7:20 ` Iain Sandoe
2021-10-08 16:26 ` Thomas Koenig
2021-10-08 19:11 ` Iain Sandoe
2021-10-08 22:55 ` Thomas Koenig
2021-10-08 23:18 ` Iain Sandoe
2021-10-09 9:11 ` Thomas Koenig
2021-10-09 9:19 ` Iain Sandoe
2021-10-09 9:25 ` Jakub Jelinek
2021-10-09 7:44 ` Andreas Schwab
2021-10-10 16:14 ` Florian Weimer
2021-10-15 13:50 ` Bill Schmidt
2021-10-15 14:20 ` Jakub Jelinek
2021-10-15 18:05 ` Thomas Koenig
2021-10-15 18:11 ` Jakub Jelinek
2021-10-15 18:58 ` Thomas Koenig
2021-10-15 22:24 ` Segher Boessenkool
2021-10-15 22:36 ` Segher Boessenkool
2021-10-18 19:02 ` Joseph Myers
2021-10-28 3:10 ` Michael Meissner
2021-10-29 3:36 ` libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches) Michael Meissner
2021-10-29 19:07 ` Thomas Koenig
2021-10-29 21:06 ` Michael Meissner
2021-11-01 15:56 ` Bill Schmidt
2021-11-02 15:40 ` Michael Meissner
2021-10-30 0:16 ` libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch) Michael Meissner
2021-10-30 9:30 ` Thomas Koenig
2021-10-30 10:03 ` Jakub Jelinek
2021-10-30 10:31 ` Thomas Koenig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2b7ce26b-0340-c1d8-8079-64f0a1d46bcd@debian.org \
--to=mckinstry@debian.org \
--cc=fortran@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jwakely@redhat.com \
--cc=schwab@linux-m68k.org \
--cc=segher@kernel.crashing.org \
--cc=tkoenig@netcologne.de \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).