From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Derek Barbosa <debarbos@redhat.com>
Cc: Wander Lairson Costa <wander@redhat.com>,
williams@redhat.com, linux-rt-users@vger.kernel.org
Subject: Re: [PATCH 0/3] Improve Makefile robustness and explicitness
Date: Tue, 11 Nov 2025 16:50:32 +0100 [thread overview]
Message-ID: <20251111155032.r8XNNyFU@linutronix.de> (raw)
In-Reply-To: <dgm5dmxmq56rtcorzcapb6ibzlch73xwqfavwtbzrbpi6ukfgv@h32wjmfahkfm>
On 2025-11-11 10:35:58 [-0500], Derek Barbosa wrote:
> Hey Sebastian,
Hi Derek,
> Part of the changes were to keep in line with what Daniel had in the makefile
> originally, and just doing some hacks to ensure that these flags are
> conditionally included based on arch support.
>
> In the case of -fcf-protection, Clark and I noticed that if a particular host
> system was using, say, the sched debug file as a parsing logic "backend" by
> specifying it in the command line, it was most likely because the system does
> not have BTF support enabled.
>
> We were particularly worried about much older systems with older compiler
> versions, which would prevent them from compiling stalld from source if they
> desired to use this legacy interface.
>
> Not sure if this answers your question at all. Sorry for the rant.
I understand. I'm just trying to say my two words here what a distro/
builder should do here and the piece of software.
On Debian, the build flags start with the "dpkg-buildflags" command
which the CFLAGS for instance (among other things). So this is might
look as follows
| CFLAGS=-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/pkg=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
on amd64. Should, for instance, -fcf-protection not be supported on
s390x it is dpkg-buildflags's job not to pass those on s390x. There
features which are enabled conditionally because not all architectures
enable/ provide them at the same time.
If the package maintainer decides to add a certain flag, such as
-fcf-protection, despite not working on all architectures then he can
keep the pieces.
In my opinion the package should not fiddle with what the upper layer
(build system) specified/ requested. It may have a default set of flags
(such as -O2 -g) which will be overwritten once the user supplied
something. The default set should not be something that is not required
and is not always provided by the compiler specified as minimum.
Sebastian
next prev parent reply other threads:[~2025-11-11 15:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 16:17 [PATCH 0/3] Improve Makefile robustness and explicitness Wander Lairson Costa
2025-11-07 16:17 ` [PATCH 1/3] Makefile: Conditionally add -mno-omit-leaf-frame-pointer Wander Lairson Costa
2025-11-07 16:17 ` [PATCH 2/3] Makefile: Improve compiler flag detection for -fcf-protection Wander Lairson Costa
2025-11-07 16:41 ` Derek Barbosa
2025-11-07 16:17 ` [PATCH 3/3] Makefile: Explicitly run the 'test' target in the tests directory Wander Lairson Costa
2025-11-11 14:50 ` [PATCH 0/3] Improve Makefile robustness and explicitness Sebastian Andrzej Siewior
2025-11-11 15:35 ` Derek Barbosa
2025-11-11 15:50 ` Sebastian Andrzej Siewior [this message]
2025-11-11 16:29 ` Derek Barbosa
2025-11-12 7:41 ` Sebastian Andrzej Siewior
2025-11-12 12:12 ` Wander Lairson Costa
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=20251111155032.r8XNNyFU@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=debarbos@redhat.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=wander@redhat.com \
--cc=williams@redhat.com \
/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