Some packages linking against ROOT "break" during runtime when ROOT is updated and they are not relinked. They issue a version-mismatch on dynamical loading, e.g. during library autoloading via ROOT: Error in <TUnixSystem::Load>: version mismatch, somelibrary.so = 53417, ROOT = 53418 Up to now, I know two of these packages (both in science-overlay): - sci-physics/vgm - sci-physics/geant-vmc I can prepare a pull-request making those depend on the subslot of ROOT later. Reproducible: Always Steps to Reproduce: 1. Install ROOT and one of the mentioned packages. Verify both work. 2. Update ROOT to a newer version. 3. Libraries of the mentioned packages cannot be loaded anymore.
+*root-5.34.18-r1 (26 Mar 2014) + + 26 Mar 2014; Sébastien Fabbro <bicatali@gentoo.org> +root-5.34.18-r1.ebuild, + -root-5.32.04.ebuild, -root-5.34.09.ebuild, -root-5.34.10-r2.ebuild, + -root-5.34.13-r1.ebuild, -root-5.34.13.ebuild, -root-5.34.15.ebuild, + metadata.xml: + Sub-slotting (bug #505358), and fixed genreflex path (bug #497280). Split all + docs into app-doc/root-docs. Cleaning up ebuild for readibility and easier + maintainship. +
Hi, thanks for the fast patching, but I believe the sub-slots need to be even "finer", i.e. SLOT="0/$(get_version_component_range 1-3 ${PV})" As you can see from my error message: Error in <TUnixSystem::Load>: version mismatch, somelibrary.so = 53417, ROOT = 53418 this also happens for 5.34.17 => 5.34.18, so a rebuild should also be triggered then (see also e.g. https://cp3.irmp.ucl.ac.be/projects/delphes/ticket/254 ). You are right that the library-version is still "libEve.so.5.34", but the version-check during dynamical loading via TSystem inside ROOT still checks the full version string. Internally, they implemented this check in "TVersionCheck.h" which has a static function that checks the version and is part of all TObject-derived classes (i.e. basically anything based on ROOT has this in). The TSystem::Load() method then just checks the result of this version-check when loading the library. This is also why neither revdep-rebuild nor preserve-libs can catch this kind of issue, but only subslotting can: Both sci-physics/vgm and sci-physics/geant-vmc do not explicitly link against ROOT, but library-loading by ROOT fails if the full version string does not match. The ugly part is you can only see this issue during runtime when the dynamic library loading by ROOT is done and fails.
thanks for the follow-up and explanation. + 27 Mar 2014; Sébastien Fabbro <bicatali@gentoo.org> root-5.34.18-r1.ebuild: + Finer sub-slotting necessary, bug #505358 +