On Thu, Aug 13, 2020 at 1:47 PM Petr Lautrbach <plautrba@xxxxxxxxxx> wrote: > > On Fri, Aug 07, 2020 at 02:54:18PM -0400, Stephen Smalley wrote: > > As noted in https://github.com/SELinuxProject/selinux/issues/245, > > symbol versioning in libsepol causes problems for LTO. libsepol and > > libsemanage have a handful of versioned symbols due to incompatible > > ABI changes made early in the CIL integration. However, as far as I > > can tell, these symbols were only used by other components of the > > selinux userspace, not externally. Should we stop supporting the old > > versions going forward and simplify the maps? If so, does this truly > > require bumping the .so version or can we omit that since there are no > > external users? Thoughts? > > > > AFAIK libsemanage is used by some 3rd parties. We've had requests to ship > libsemanage-devel in RHEL-8 repositories in order customers build their > applications. > > > From my packager POV I like symbol versioning - it helps to prevent some > dependency issues in development branches, e.g. when libsemanage is built with > new libsepol symbol but the new package doesn't require newer libsepol. rpm is > able to solve that: > > $ rpm -q --requires libsemanage > ... > libselinux(x86-64) >= 3.1-2 > libselinux.so.1()(64bit) > libselinux.so.1(LIBSELINUX_1.0)(64bit) > libsepol.so.1()(64bit) > libsepol.so.1(LIBSEPOL_1.0)(64bit) > libsepol.so.1(LIBSEPOL_1.1)(64bit) > libsepol.so.1(LIBSEPOL_3.0)(64bit) > ... > > $ rpm -q --provides libsemanage > config(libsemanage) = 3.1-2.fc33 > libsemanage = 3.1-2.fc33 > libsemanage(x86-64) = 3.1-2.fc33 > libsemanage.so.1()(64bit) > libsemanage.so.1(LIBSEMANAGE_1.0)(64bit) > libsemanage.so.1(LIBSEMANAGE_1.1)(64bit) > > > LTO seems to cause problems to other projects as well > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/XMIQMN5KNAZUPX6O3LN6JJGTCZTP4B7J/ > > So I'd prefer if we try to do and use symbol versioning correctly, but it's not > hard requirement from my side. Ok. An alternative to dropping it altogether is just to try to fix the particular problem he is seeing with the duplicated symbols in LIBSEPOL_1_0 and LIBSEPOL_1_1. If we can remove the duplicate without breaking anything, then that might suffice for LTO. I'm not actually clear on whether it is correct - there are technically two different versions of the symbol aliased via symver. If the seeming duplicate is required then I guess we just have to wait for LTO support to catch up with symbol versioning.
