Kevin Fenzi <ke...@scrye.com> wrote: > On Tue, 1 Dec 2015 15:46:26 +0100 > Björn Persson <bj...@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 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. > > 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? 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? Björn Persson
pgpu5YNGHDu64.pgp
Description: OpenPGP digital signatur
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
