From: Alyssa Ross <hi@alyssa.is>
To: Nicolas Iooss <nicolas.iooss@m4x.org>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH] Support static-only builds
Date: Sat, 13 Nov 2021 13:52:37 +0000 [thread overview]
Message-ID: <87lf1scgd6.fsf@alyssa.is> (raw)
In-Reply-To: <CAJfZ7=mmv1FxAP0FY=mDZvUDhQx3f4zzB0OHP-M-P1OWx_ZJjg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]
Nicolas Iooss <nicolas.iooss@m4x.org> writes:
> On Thu, Nov 11, 2021 at 5:42 PM Alyssa Ross <hi@alyssa.is> 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@alyssa.is>
>
> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
prev parent reply other threads:[~2021-11-13 13:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 16:42 [PATCH] Support static-only builds Alyssa Ross
2021-11-11 22:37 ` Nicolas Iooss
2021-11-13 13:52 ` Alyssa Ross [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lf1scgd6.fsf@alyssa.is \
--to=hi@alyssa.is \
--cc=nicolas.iooss@m4x.org \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.