From: William Roberts <bill.c.roberts@gmail.com>
To: Laurent Bigonville <bigon@debian.org>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: CFLAGS overridden by distribution build system
Date: Sat, 23 May 2020 10:59:18 -0500 [thread overview]
Message-ID: <CAFftDdobT3E1MvFptyAKLBJ73KyrMOSS3m8DCnPX9+QF-Rk24Q@mail.gmail.com> (raw)
In-Reply-To: <d0fd6970-7aa6-c576-fb8a-1d1293416e97@debian.org>
On Sat, May 23, 2020 at 5:57 AM Laurent Bigonville <bigon@debian.org> wrote:
>
> Hello,
>
> The current build system of the userspace is setting a lot of CFLAGS,
> but most of these are overridden by the distributions when building.
>
> Today I received a bug report[0] from Christian Göttsche asking me to
> set -fno-semantic-interposition again in libsepol. I see also the same
> flag and also a lot of others set in libselinux and libsemanage build
> system.
Why would it be again? The old DSO design made that option impotent.
Clang does it by default.
>
> For what I understand some of these are just needed for code quality
> (-W) and could be controlled by distributions but others might actually
> need to be always set (-f?).
If you look at the Makefiles overall in all the projects, you'll see hardening
flags, etc. Libsepol has a pretty minimal set compared to say libselinux, but
they all get overridden by build time CFLAGS if you want.
>
> Shouldn't the flags that always need to be set (which ones?) be moved to
> a "override CFLAGS" directive to avoid these to be unset by distributions?
If you we're cleaver with CFLAGS before, you could acually circumvent
the buildtime
DSO stuff. While i'm not opposed to adding it to immutable flag, if
you're setting
CFLAGS, you're on your own. At least with the current design.
I have no issues with adding it to override, but we would have to
overhaul a bunch
of them and make them consistent.
>
> Kind regards,
>
> Laurent Bigonville
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961329
>
next prev parent reply other threads:[~2020-05-23 15:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-23 10:56 CFLAGS overridden by distribution build system Laurent Bigonville
2020-05-23 15:59 ` William Roberts [this message]
2020-05-29 13:31 ` Stephen Smalley
2020-05-29 16:04 ` William Roberts
2020-05-29 16:40 ` Stephen Smalley
2020-05-29 17:15 ` William Roberts
2020-05-29 18:18 ` Stephen Smalley
2020-05-29 20:59 ` William Roberts
2020-06-01 9:34 ` Petr Lautrbach
2020-06-02 18:55 ` [PATCH] README: start a section for documenting CFLAGS bill.c.roberts
2020-06-04 19:03 ` Stephen Smalley
2020-06-08 15:37 ` [PATCH v2] " bill.c.roberts
2020-06-08 16:21 ` Stephen Smalley
2020-06-08 22:34 ` William Roberts
2020-06-08 22:38 ` [PATCH v3] " bill.c.roberts
2020-06-09 11:57 ` Stephen Smalley
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=CAFftDdobT3E1MvFptyAKLBJ73KyrMOSS3m8DCnPX9+QF-Rk24Q@mail.gmail.com \
--to=bill.c.roberts@gmail.com \
--cc=bigon@debian.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).