linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Crystal Wood <crwood@redhat.com>
To: debarbos@redhat.com
Cc: clrkwllms@kernel.org, linux-rt-users@vger.kernel.org, wander@redhat.com
Subject: Re: [PATCH 2/3] Makefile: Add support for legacy kernels
Date: Wed, 08 Oct 2025 16:38:49 -0500	[thread overview]
Message-ID: <20cee89c557ca65b99637d49508c62f8a636f846.camel@redhat.com> (raw)
In-Reply-To: <6wtktjmptvddkeo3wibqjignaofyupiowxwsug4xp5inekvn24@qriseqkmhke6>

On Wed, 2025-10-08 at 14:41 -0400, Derek Barbosa wrote:
> On Wed, Oct 08, 2025 at 11:50:11AM -0500, Crystal Wood wrote:
> > The default, if no C language dialect options are given, is -std=gnu90; this
> > will change to -std=gnu99 or -std=gnu11 in some future release when the C99 or
> > C11 support is complete.

I meant, why can't we specify c99 regardless of legacy (which would also
help avoid introducing new stuff that breaks on legacy)?  Unless
something in queue_track.c already does need newer than c99.

> > > When building on RHEL-7, it was though SOPTS still make their way through, even
> > > though the comment specifies that these are variables that only come from the
> > > specfile for DNF-family distributions.I was getting errors due to annobin not
> > > being present, so I stripped it out.
> > 
> > Oh, I was looking for "annocheck" which explains why I didn't notice
> > that.
> > 
> > So the issue is that when you *are* building an RPM, the specfile isn't
> > passing the right things for that OS version?  Wouldn't that be an
> > issue with the specfile?
> > 
> 
> It would be. However, annocheck/annobin gets invoked by default `make`.
> 
> ```
> ifeq ($(RPMCFLAGS),)
> CFLAGS  :=      -DVERSION=\"$(VERSION)\" $(FOPTS) $(MOPTS) $(WOPTS) $(SOPTS) $(DEFS)
> else
> CFLAGS  :=       $(RPMCFLAGS) $(DEFS)
> endif
> ```
> 
> On `main`, with just disabling USE_BPF:
> 
> ```
> [root@rt-qe-06 stalld]# make USE_BPF=0
> ARCH=x86_64
> USE_BPF=0
> FCF_PROTECTION=-fcf-protection
> MTUNE=-mtune=generic
> CFLAGS=-DVERSION=\"1.23.1\" -flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -fcf-protection -fpie -mtune=generic -m64 -mno-omit-leaf-frame-pointer -Wall -Werror=format-security -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -DUSE_BPF=0 -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -DDEBUG_STALLD=0 -g -O2
> LDFLAGS=-ggdb -znow -pie
> gcc -DVERSION=\"1.23.1\" -flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -fcf-protection -fpie -mtune=generic -m64 -mno-omit-leaf-frame-pointer -Wall -Werror=format-security -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -DUSE_BPF=0 -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -DDEBUG_STALLD=0 -g -O2   -c -o src/stalld.o src/stalld.c
> gcc: error: /usr/lib/rpm/redhat/redhat-annobin-cc1: No such file or directory
> make: *** [src/stalld.o] Error 1

Yeah, that's the "why is a basic 'make' pulling in Red Hat stuff?"
question.

> [root@rt-qe-06 stalld]# make USE_BPF=0 SOPTS= FCF_PROTECTION=
> ARCH=x86_64
> USE_BPF=0
> FCF_PROTECTION=
> MTUNE=-mtune=generic
> CFLAGS=-DVERSION=\"1.23.1\" -flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer  -fpie -mtune=generic -m64 -mno-omit-leaf-frame-pointer -Wall -Werror=format-security  -DUSE_BPF=0 -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -DDEBUG_STALLD=0 -g -O2
> LDFLAGS=-ggdb -znow -pie
> gcc -DVERSION=\"1.23.1\" -flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer  -fpie -mtune=generic -m64 -mno-omit-leaf-frame-pointer -Wall -Werror=format-security  -DUSE_BPF=0 -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -DDEBUG_STALLD=0 -g -O2   -c -o src/stalld.o src/stalld.c
> In file included from src/stalld.c:39:0:
> src/queue_track.h: In function ‘find_queued_task’:
> src/queue_track.h:61:2: error: ‘for’ loop initial declarations are only allowed in C99 mode
>   for (unsigned int i = 0;  \
>   ^
> src/queue_track.h:118:2: note: in expansion of macro ‘for_each_task_entry’
>   for_each_task_entry(cpu_data, task) {
>   ^
> src/queue_track.h:61:2: note: use option -std=c99 or -std=gnu99 to compile your code
>   for (unsigned int i = 0;  \
>   ^
> src/queue_track.h:118:2: note: in expansion of macro ‘for_each_task_entry’
>   for_each_task_entry(cpu_data, task) {
>   ^
> make: *** [src/stalld.o] Error 1
> ```

So I guess the makefile's definition of HDR is wrong, and it turns out
HDR isn't even used anywhere :-P

> 
> Appending c99 to the CFLAGS on the command-line a-la `CFLAGS+=-std=c99`
> overrides the cflags entirely... so editing the CFLAGS to append -std=c99..

You're saying that if you do CFLAGS+=-std=c99 the only thing in CFLAGS
is -std=c99?  That shouldn't happen...

-Crystal


  reply	other threads:[~2025-10-08 21:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-02 20:55 [PATCH 0/3] stalld: Improve legacy kernel support and unify sched_debug parsing Derek Barbosa
2025-10-02 20:55 ` [PATCH 1/3] sched_debug: Unify parsing methods for task_info Derek Barbosa
2025-10-02 20:55 ` [PATCH 2/3] Makefile: Add support for legacy kernels Derek Barbosa
2025-10-07 16:43   ` Clark Williams
2025-10-07 18:50   ` Crystal Wood
2025-10-08 13:07     ` Derek Barbosa
2025-10-08 16:50       ` Crystal Wood
2025-10-08 18:41         ` Derek Barbosa
2025-10-08 21:38           ` Crystal Wood [this message]
2025-10-08 23:52             ` Derek Barbosa
2025-10-10  4:07               ` Crystal Wood
2025-10-17 13:16           ` Clark Williams
2025-10-20 16:54             ` Crystal Wood
2025-10-20 18:18               ` Derek Barbosa
2025-10-17 13:20     ` Clark Williams
     [not found]     ` <CAMLffL_a2-RkOJg8kXPZSKhzenu9aPDs4SBz-F97y9-wa_oHHQ@mail.gmail.com>
2025-10-20 16:48       ` Crystal Wood
2025-10-21 13:04         ` Clark Williams
2025-10-02 20:55 ` [PATCH 3/3] scripts: fix run-local if bashism Derek Barbosa
2025-10-07 16:42   ` Clark Williams

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=20cee89c557ca65b99637d49508c62f8a636f846.camel@redhat.com \
    --to=crwood@redhat.com \
    --cc=clrkwllms@kernel.org \
    --cc=debarbos@redhat.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=wander@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;
as well as URLs for NNTP newsgroup(s).