Nicolas Iooss <nicolas.iooss@xxxxxxx> writes: > On Thu, Nov 11, 2021 at 5:42 PM Alyssa Ross <hi@xxxxxxxxx> wrote: >> >> Sometimes it's useful to have a static-only toolchain. This can be >> due to targetting some weird embedded platform, or it can be because >> it ensures that no dynamic libraries are sneaking into a system that's >> supposed to be 100% static due to non-cooperative build systems. Most >> build systems support static-only builds, e.g. autoconf provides a >> --disable-shared configure option. >> >> libselinux's custom make-based build system did not support such an >> option, so here I've added one. Apart from the obvious changes, I had >> to make the utilities that use libpcre link against it manually, >> because that can't be inferred from the static libselinux. For >> downstream users of libselinux using pkg-config, this shouldn't be a >> problem, because libselinux.pc already includes the Requires.private >> line that specifies libpcre should be linked against as well. >> >> Signed-off-by: Alyssa Ross <hi@xxxxxxxxx> > > Hello, > > Thanks for your patch. It is interesting (as a maintainer) to see that > some SELinux users are still interested in having the static > libraries, as in the past there were messages about users who only > wanted the .so on their systems, if I remember correctly. > > Your patch looks right, except for one detail (which I put inline). > Nevertheless I am wondering about how future changes will not break > your use-case and I am thinking of adding a "DISABLE_SHARED=y" > configuration to our Continuous Integration system. More precisely it > would be nice to have something similar to what is currently done to > test various build configurations in > https://github.com/SELinuxProject/selinux/blob/3.3/.github/workflows/run_tests.yml#L84-L94 > . Currently when I try to test it, it fails when linking > libsemanage.so: > > /usr/bin/ld: /destdir/usr/lib/libselinux.a(seusers.o): warning: > relocation against `stderr@@GLIBC_2.2.5' in read-only section `.text' > /usr/bin/ld: /destdir/usr/lib/libselinux.a(seusers.o): relocation > R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used > when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: bad value > > This build failure is normal, as the files in libselinux.a are not > compiled with -fPIC and cannot be integrated in libsemanage.so. Did > you also modify libsemanage (and other tools) to also use the static > libraries? My purposes didn't require libsemanage, so I hadn't tried, but indeed I wasn't able to build it. The next version of my patch will add DISABLE_SHARED support to libsemanage and policycoreutils as well. I've now also tested checkpolicy and semodule-utils, which worked without any further changes. > This failure also happens when linking the Python bindings (with "make > install-pywrap"). Are you using bindings to Python or Ruby in your > project? No, and I'd expect that it wouldn't be possible, since I assume the bindings have to be shared libraries so they can be dlopened by the language runtimes? Maybe it would be possible to link static binding libraries with the interpreter, but I've never heard of anybody doing that…
Attachment:
signature.asc
Description: PGP signature
