On Mon, 7 Dec 2015 11:32:44 +0100
Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
Kevin Fenzi <kevin(a)scrye.com> wrote:
> On Tue, 1 Dec 2015 15:46:26 +0100
> Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
> > GPRbuild is
> > linked to XMLada, and both GPRbuild and XMLada are linked to
> > libgnat, as are all other Ada programs and libraries.
> >
> > With every major GCC upgrade the soname of libgnat changes, and
> > all the Ada packages stop working until they get rebuilt. But
> > rebuilding requires a working GPRbuild.
> >
> > Previously a catch-22 was avoided because XMLada and GPRbuild were
> > built with Gnatmake, which is built as a part of GCC. Now they're
> > both built with GPRbuild instead, and Gnatmake is emitting
> > warnings that it's going to lose support for the project files
> > that control the build. The next GCC upgrade will make the
> > problem acute.
>
> How are others supposed to handle this?
Other users of the GNAT toolchain? Well, if they don't use Koji then
maybe Kevin meant other distros - Debian, OpenSUSE - they all use a
buildsystem
they can simply keep the old libgnat around, alongside the new
libgnat
and the rest of the new GCC, until XMLada and GPRbuild have been
rebuilt. On the file level there is no problem. The library filenames
are versioned so they can coexist. The soname ensures that the right
one will be loaded when GPRbuild runs, and the symlink "libgnat.so"
ensures that linking will be done with the newest library.
This works on the RPM level too by the way. Two libgnat packages can
be installed at the same time.
Handling XMLada is slightly trickier. The rebuilt XMLada will have the
same soname as the old one (unless they upgrade both GCC and XMLada at
the same time), so they need to install it to a staging directory and
add that directory to the search path when rebuilding GPRbuild. Then
the old XMLada and the old libgnat will be loaded when the old
GPRbuild runs, and the rebuilt GPRbuild will be linked to the rebuilt
XMLada, which is linked to the new libgnat. Then they can copy the
rebuilt GPRbuild and the rebuilt XMLada into place together, and
remove the old libraries.
With a little patch to a project file it would also be possible to add
a suffix to the soname of XMLada. Then the two instances of XMLada
could coexist the same way as the two versions of libgnat, and the
staging directory wouldn't be needed.
They can also get rid of the whole problem by linking GPRbuild
statically. This seems to be what Adacore themselves do. The compiled
GPRbuild they distribute requires only libpthread.so.0, librt.so.1 and
libc.so.6, so libgnat and XMLada must have been statically linked in.
I would consider static linking for GPRbuild in this situation
acceptable
> > So now you're saying that the GCC package, whose spec
is already
> > 3000 lines long, needs to contain an entire additional GCC and
> > build large parts of it, just to work around a limitation in
> > Koji? I can of course ask the GCC maintainer, but I fully expect
> > that he'll refuse.
>
> I'm just explaining how koji works here, don't shoot me. ;)
>
> So, ideally here, there's a new gcc upgrade, the gcc maintainer
> would build with a compat-libgnat subpackage that installs libgnat
> in another place. Then they build the new gcc without it. You then
> can buildrequire that compat-libgnat so you can rebuild other
> things, then finally do another rebuild without compat-libgnat to
> bring everything up on the current gcc.
If I understand this correctly, you mean that the compat-libgnat
subpackage would remain in the buildroot even after the other
subpackages were replaced with the later build. Is that right? I
always thought that when packages are tagged into buildroots, side
tags and stuff, then all the subpackages from a single source package
are added or removed together. If it's done with subpackage
granularity, then that makes things a bit easier.
Then I have some questions about that method:
Why should libgnat be installed in another place? It seems to me that
it could be in /usr/lib64 as usual, thanks to the versioned filenames.
Would an explicit "BuildRequires: compat-libgnat" be needed? Wouldn't
it automatically provide the soname as usual?
no, the binary will bring the compat library via the automaticaly
managed soname Requires/Provides
Would someone need to manually remove the compat package from the
buildroot afterwards? Is that what usually happens when a package
drops a subpackage, that the subpackage lingers in the buildroot
unless someone removes it?
no, the buildroots as created by resolving Requires and Provides, if
nothing (no binary) will use the library with the old soname, it won't
be be dragged into the buildroot
Dan