On Mon, Aug 24, 2020 at 10:15:27AM -0400, Stephen Smalley wrote: > 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? > I'd go with 2 - get rid of old symbols, drop duplication from .map file and bump .so version. I could prepare a patch with this next week.
Attachment:
signature.asc
Description: PGP signature
