On Tue, Aug 18, 2020 at 9:40 AM Petr Lautrbach <plautrba@xxxxxxxxxx> wrote: > > On Thu, Aug 13, 2020 at 01:56:57PM -0400, Stephen Smalley wrote: > > 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. > > > > In this particular case I'd drop duplicate symbols from libsepol. It's about 4 > years and 5 releases since it was added and it would slightly clean the code. It > would be properly announced in release notes. And if there's anybody else then > libsemage who uses it they would need either to rebuild their sources or stay > with the current version. Not entirely sure what this means. We can do either of the following options: 1. Just remove the duplicated symbol names from libsepol.map.in (i.e. only define them once in either LIBSEPOL_1.0 or LIBSEPOL_1.1 not in both). That might solve the problem for LTO without creating any compatibility issues for non-LTO; I'm not sure. -or- 2. Get rid of the duplicated symbols in libsepol.map.in AND drop the old symbol definitions and the old functions from cil/src/cil.c, renaming the new symbols to the exported name and dropping use of symver there. This is an ABI change for libsepol but likely only affects libsemanage. If we do this, do we bump its .so version to reflect the incompatible change?
