[OS-BUILD PATCH] redhat/kernel.spec.template: Fix intel-speed-select compile

[Prarit Bhargava (via Email Bridge)]

From: Prarit Bhargava <prarit(a)redhat.com&gt;

redhat/kernel.spec.template: Fix intel-speed-select compile

The intel-speed-select utility needs the libnl3 library to compile.

Signed-off-by: Prarit Bhargava <prarit(a)redhat.com&gt;

diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -2246,7 +2246,7 @@ chmod +x tools/power/cpupower/utils/version-gen.sh
    %{tools_make}
    popd
    pushd tools/power/x86/intel-speed-select
-   %{make}
+   %{make} CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3"
LDFLAGS+="-lnl-genl-3 -lnl-3"
    popd
 %endif
 %endif
@@ -2511,7 +2511,7 @@ install -m644 %{SOURCE2001}
%{buildroot}%{_sysconfdir}/sysconfig/cpupower
    %{tools_make} DESTDIR=%{buildroot} install
    popd
    pushd tools/power/x86/intel-speed-select
-   %{tools_make} CFLAGS+="-D_GNU_SOURCE -Iinclude" DESTDIR=%{buildroot}
install
+   %{make} CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3"
LDFLAGS+="-lnl-genl-3 -lnl-3" DESTDIR=%{buildroot} install
    popd
 %endif
 pushd tools/thermal/tmon

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8947...

This does not work, testing another fix and will update the MR if that works.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8950...

So this papers over the real problem. I looked at the Makefile and wonder why
CFLAGS wasn't being passed over even with "override" being used to append
the
flags. Seems the real problem is that the updated CFLAGS aren't being passed
to the submake used to build the tool. I did this here and it seems to have
fixed the problem:

```
$ git diff
diff --git a/tools/power/x86/intel-speed-select/Makefile
b/tools/power/x86/intel-speed-select/Makefile
index d2fba1297d96..0858aba12d21 100644
--- a/tools/power/x86/intel-speed-select/Makefile
+++ b/tools/power/x86/intel-speed-select/Makefile
@@ -40,7 +40,7 @@ prepare: $(OUTPUT)include/linux/isst_if.h
$(OUTPUT)include/linux/thermal.h
 ISST_IN := $(OUTPUT)intel-speed-select-in.o

 $(ISST_IN): prepare FORCE
-       $(Q)$(MAKE) $(build)=intel-speed-select
+       $(Q)$(MAKE) CFLAGS="$(CFLAGS)" $(build)=intel-speed-select
 $(OUTPUT)intel-speed-select: $(ISST_IN)
        $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $< -o $@


```

I'm not a make expert, so there may be a better solution. But with above, at
least the proper CFLAGS are being given now (the additional ones given in the
override line). This also is more future proof in case more flags/include
directives are given through CFLAGS.

[Prarit Bhargava]

On 3/30/22 15:10, Herton R. Krzesinski (via Email Bridge) wrote:
>  From: Herton R. Krzesinski on gitlab.com
>  https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8950...
>  
>  So this papers over the real problem. I looked at the Makefile and wonder why
>  CFLAGS wasn't being passed over even with "override" being used to append
> the
>  flags. Seems the real problem is that the updated CFLAGS aren't being passed
>  to the submake used to build the tool. I did this here and it seems to have
>  fixed the problem:
>  
>  ```
>  $ git diff
>  diff --git a/tools/power/x86/intel-speed-select/Makefile
>  b/tools/power/x86/intel-speed-select/Makefile
>  index d2fba1297d96..0858aba12d21 100644
>  --- a/tools/power/x86/intel-speed-select/Makefile
>  +++ b/tools/power/x86/intel-speed-select/Makefile
>  @@ -40,7 +40,7 @@ prepare: $(OUTPUT)include/linux/isst_if.h
>  $(OUTPUT)include/linux/thermal.h
>    ISST_IN := $(OUTPUT)intel-speed-select-in.o
>  
>    $(ISST_IN): prepare FORCE
>  -       $(Q)$(MAKE) $(build)=intel-speed-select
>  +       $(Q)$(MAKE) CFLAGS="$(CFLAGS)" $(build)=intel-speed-select
>    $(OUTPUT)intel-speed-select: $(ISST_IN)
>           $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
>   
Interesting.  Adding DJ as I've been discussing the problem with him.

P.

>  
>  ```
>  
>  I'm not a make expert, so there may be a better solution. But with above, at
>  least the proper CFLAGS are being given now (the additional ones given in the
>  override line). This also is more future proof in case more flags/include
>  directives are given through CFLAGS.
>  _______________________________________________
>  kernel mailing list -- kernel(a)lists.fedoraproject.org
>  To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[DJ Delorie]

Prarit Bhargava <prarit(a)redhat.com&gt; writes:
> > So this papers over the real problem. I looked at the Makefile
> and wonder why
> > CFLAGS wasn't being passed over even with "override" being used to
> append the
> > flags. Seems the real problem is that the updated CFLAGS aren't being passed
> > to the submake used to build the tool. I did this here and it seems to have
> > fixed the problem: 
There's a HUGE difference between "CFLAGS=x make" and "make
CFLAGS=x",
or setting CFLAGS inside a Makefile.  That make treats environment
variables as makefile variables doesn't mean they're equal.

Make variables are NOT passed to child processes if they originate in
the Makefile, but environment variables are, and sometimes make
variables start off as environment variables, which can make it seem
otherwise:

    When 'make' runs a recipe, variables defined in the makefile are
  placed into the environment of each shell.  This allows you to pass
  values to sub-'make' invocations (*note Recursive Use of 'make':
  Recursion.).  By default, only variables that came from the
  environment or the command line are passed to recursive invocations.
  You can use the 'export' directive to pass other variables.  *Note
  Communicating Variables to a Sub-'make': Variables/Recursion, for full
  details.

I will add that, noted during testing, using the "FLAG+=something" form
on the command line does NOT trigger the "from the command line" rule if
the FLAG otherwise didn't trigger it itself.  This might be the specific
case here.

So I don't think this is papering over the real problem, I think this is
the right solution (or use export), for when you don't collect such
variables in a .included file.

> > ```
> > $ git diff
> > diff --git a/tools/power/x86/intel-speed-select/Makefile
> > b/tools/power/x86/intel-speed-select/Makefile
> > index d2fba1297d96..0858aba12d21 100644
> > --- a/tools/power/x86/intel-speed-select/Makefile
> > +++ b/tools/power/x86/intel-speed-select/Makefile
> > @@ -40,7 +40,7 @@ prepare: $(OUTPUT)include/linux/isst_if.h
> > $(OUTPUT)include/linux/thermal.h
> >   ISST_IN := $(OUTPUT)intel-speed-select-in.o
> > 
> >   $(ISST_IN): prepare FORCE
> > -       $(Q)$(MAKE) $(build)=intel-speed-select
> > +       $(Q)$(MAKE) CFLAGS="$(CFLAGS)" $(build)=intel-speed-select 
You could throw an "env" in there somewhere to see what ended up in the
environment (and thus passed down by default) and what didn't.

[David Arcari]

Hi Herton,

On 3/30/22 5:16 PM, Prarit Bhargava wrote:
>  On 3/30/22 15:10, Herton R. Krzesinski (via Email Bridge) wrote:
> > From: Herton R. Krzesinski on gitlab.com
> > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8950... 
> >
> >
> > So this papers over the real problem. I looked at the Makefile and 
> > wonder why
> > CFLAGS wasn't being passed over even with "override" being used to 
> > append the
> > flags. Seems the real problem is that the updated CFLAGS aren't being 
> > passed
> > to the submake used to build the tool. I did this here and it seems to 
> > have
> > fixed the problem: 
Subsequently, didn't you hit an issue with linking?   Doesn't the same 
issue exist with LDFLAGS?  That's what we seemed to see after we kludged 
around the CFLAGS issue.

-DA

> >
> > ```
> > $ git diff
> > diff --git a/tools/power/x86/intel-speed-select/Makefile
> > b/tools/power/x86/intel-speed-select/Makefile
> > index d2fba1297d96..0858aba12d21 100644
> > --- a/tools/power/x86/intel-speed-select/Makefile
> > +++ b/tools/power/x86/intel-speed-select/Makefile
> > @@ -40,7 +40,7 @@ prepare: $(OUTPUT)include/linux/isst_if.h
> > $(OUTPUT)include/linux/thermal.h
> >   ISST_IN := $(OUTPUT)intel-speed-select-in.o
> >
> >   $(ISST_IN): prepare FORCE
> > -       $(Q)$(MAKE) $(build)=intel-speed-select
> > +       $(Q)$(MAKE) CFLAGS="$(CFLAGS)" $(build)=intel-speed-select
> >   $(OUTPUT)intel-speed-select: $(ISST_IN)
> >          $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
> >
>  
>  Interesting.  Adding DJ as I've been discussing the problem with him.
>  
>  P.
>  
> >
> > ```
> >
> > I'm not a make expert, so there may be a better solution. But with 
> > above, at
> > least the proper CFLAGS are being given now (the additional ones given 
> > in the
> > override line). This also is more future proof in case more flags/include
> > directives are given through CFLAGS.
> > _______________________________________________
> > kernel mailing list -- kernel(a)lists.fedoraproject.org
> > To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/[e-mail] 
> >
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
>  _______________________________________________
>  kernel mailing list -- kernel(a)lists.fedoraproject.org
>  To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail] 
>  
>  Do not reply to spam on the list, report it: 
>  https://pagure.io/fedora-infrastructure

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8952...

>  CKI Gitlab commented:
>
>
>  DJ Delorie <dj(a)redhat.com&gt; commented via email:
>  ```
>  Prarit Bhargava <prarit(a)redhat.com&gt; writes:
>  >> So this papers over the real problem. I looked at the Makefile and wonder
why
>  >> CFLAGS wasn't being passed over even with
> "override" being used to append 
the
>  >> flags. Seems the real problem is that the updated CFLAGS
> aren't being 
passed
>  >> to the submake used to build the tool. I did this here and
> it seems to 
have
>  >> fixed the problem:
>
>  There's a HUGE difference between "CFLAGS=x make" and "make
> CFLAGS=x",
>  or setting CFLAGS inside a Makefile.  That make treats environment
>  variables as makefile variables doesn't mean they're equal.
>
>  Make variables are NOT passed to child processes if they originate in
>  the Makefile, but environment variables are, and sometimes make
>  variables start off as environment variables, which can make it seem
>  otherwise:
>
>      When 'make' runs a recipe, variables defined in the makefile are
>    placed into the environment of each shell.  This allows you to pass
>    values to sub-'make' invocations (*note Recursive Use of 'make':
>    Recursion.).  By default, only variables that came from the
>    environment or the command line are passed to recursive invocations.
>    You can use the 'export' directive to pass other variables.  *Note
>    Communicating Variables to a Sub-'make': Variables/Recursion, for full
>    details. 
Ok so this is what I did here:

$ git diff
diff --git a/tools/power/x86/intel-speed-select/Makefile
b/tools/power/x86/intel-speed-select/Makefile
index d2fba1297d96..577216629f91 100644
--- a/tools/power/x86/intel-speed-select/Makefile
+++ b/tools/power/x86/intel-speed-select/Makefile
@@ -40,6 +40,7 @@ prepare: $(OUTPUT)include/linux/isst_if.h
$(OUTPUT)include/linux/thermal.h
 ISST_IN := $(OUTPUT)intel-speed-select-in.o

 $(ISST_IN): prepare FORCE
+       env
        $(Q)$(MAKE) $(build)=intel-speed-select
 $(OUTPUT)intel-speed-select: $(ISST_IN)
        $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $< -o $@

Then doing:

$ CFLAGS="-Os" make V=1
...
MAKEFLAGS=r -- V=1
...
CFLAGS=-Os -O2 -Wall -g -D_GNU_SOURCE -Iinclude -I/usr/include/libnl3
...
make -f /home/herton/repo-git/ark/kernel-ark/tools/build/Makefile.build dir=.
obj=intel-speed-select
make[1]: Entrando no diretório '/home/herton/repo-git/ark/kernel-
ark/tools/power/x86/intel-speed-select'

  gcc -Wp,-MD,./.isst-config.o.d -Wp,-MT,isst-config.o -Os -O2 -Wall -g
-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3 -D"BUILD_STR(s)=#s" -c -o isst-
config.o isst-config.c
...


$ make V=1 CFLAGS="-Os"
...
MAKEFLAGS=r -- CFLAGS=-Os V=1
...
CFLAGS=-Os -O2 -Wall -g -D_GNU_SOURCE -Iinclude -I/usr/include/libnl3
...
make -f /home/herton/repo-git/ark/kernel-ark/tools/build/Makefile.build dir=.
obj=intel-speed-select
make[1]: Entrando no diretório '/home/herton/repo-git/ark/kernel-
ark/tools/power/x86/intel-speed-select'

  gcc -Wp,-MD,./.isst-config.o.d -Wp,-MT,isst-config.o -Os -D"BUILD_STR(s)=#s"
-c -o isst-config.o isst-config.c
...


So yes as you say there is a difference in supplying CFLAGS as Makefile
variable
or environment variable. In the case of supplied as variable it's overriding
CFLAGS in the submake.

>  I will add that, noted during testing, using the "FLAG+=something" form
>  on the command line does NOT trigger the "from the command line" rule if
>  the FLAG otherwise didn't trigger it itself.  This might be the specific
>  case here. 
Using += doesn't change behaviour, same behaviour (bash should interpret env
assignment and later option make right, same result). So I don't think it's
related to += usage.

>  So I don't think this is papering over the real problem, I think this is
>  the right solution (or use export), for when you don't collect such
>  variables in a .included file. 
The paper over I mention is the solution used on the kernel.spec, which is
using the override option but that will break if upstream updates Makefile
and adds more stuff to CFLAGS needed to build. But I think we want to use the
environment variable form in the spec so it works (thanks for pointing the
difference). So instead of current patch:

%{make} CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3"
LDFLAGS+="-lnl-genl-3 -lnl-3"

We probably want to make it:

CFLAGS="%{?build_hostcflags}" LDFLAGS="%{?build_hostldflags}" %{make}

And probably we should audit other tool builds as well to see if we are not
bumping into same problem.

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8960...

Right, so I did

`%{make} CFLAGS="${RPM_OPT_FLAGS} -D_GNU_SOURCE -I/usr/include/libnl3"
LDFLAGS="%{__global_ldflags} -lnl-genl-3 -lnl-3`

In the kernel spec and that got around both issues there. Of course we are
still running into a failure on gcc12, but that is a code issue.
Unfortunately I still can't get a build through until I get that figured out,
and the new issue with iio_event_monitor.

[Don Zickus (via Email Bridge)]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8960...

I know jolsa had similar issues a couple of years ago with perf.  He put some
interesting workarounds in the spec file to deal with them, "perf_make".  Is
that something we can mimic/leverage here?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8960...

That's pretty much what I did, but not a whole lot of point in pushing it
until things actually build.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8961...

what about if you change it just to:

```
CFLAGS="%{?build_hostcflags}" LDFLAGS="%{?build_hostldflags}"
{__make}
```

btw, I was not able to reproduce locally the problem with LDFLAGS.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8961...

well, we already are using the perf_make idea by defining a make macro in the
spec. But that's not working in this case due how make is behaving

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8961...

I mean, once I change the Makefile to use ```+       $(Q)$(MAKE)
CFLAGS="$(CFLAGS)" $(build)=intel-speed-select```, the LDFLAGS issue didn't
reproduce/break linking.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8961...

I see the LDFLAGS now, let me check it...

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8962...

It does work with the version I have locally, but until I can get a build
through to verify, I was not planning to send the update.  The other issue is
in iio_event_monitor, which wouldn't be a problem at all if we already had
kernel-headers from 5.18, and not related to this.

I much prefer the idea of doing this in spec at least initially vs carrying a
patch.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8962...

So the LDFLAGS issue manifests itself because %{?build_hostldflags} (which
comes from our redhat rpm config) contains the flag -Wl,--as-needed, and once
we fix the passing of LDFLAGS as we are trying here, the problem manifests.
Now how to fix the failure is something still to investigate.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8962...

Yes it's possible to do it in spec, and right now I'm in favour of it as well.
However for the intel-speed-select issue, if we fix LDFLAGS right now we will
have the linker failure... I think that to fix properly we will need to ajust
the Makefile, but can workaround by omitting -Wl,--as-needed or not providing
the LDFLAGS from our redhat rpm config temporarily.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8963...

So the problem with LDFLAGS is the linking order when using -Wl,--as-needed

We need this fix into the Makefile:

```
$ git diff
diff --git a/tools/power/x86/intel-speed-select/Makefile
b/tools/power/x86/intel-speed-select/Makefile
index d2fba1297d96..8a6b278b3ca9 100644
--- a/tools/power/x86/intel-speed-select/Makefile
+++ b/tools/power/x86/intel-speed-select/Makefile
@@ -42,7 +42,7 @@ ISST_IN := $(OUTPUT)intel-speed-select-in.o
 $(ISST_IN): prepare FORCE
        $(Q)$(MAKE) $(build)=intel-speed-select
 $(OUTPUT)intel-speed-select: $(ISST_IN)
-       $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
+       $(QUIET_LINK)$(CC) $(CFLAGS) $< -o $@ $(LDFLAGS)

 clean:
        rm -f $(ALL_PROGRAMS)
```

With the above fix, I can do:

```
CFLAGS="-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-
protection" LDFLAGS="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1" /usr/bin/make V=1
```

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8967...

Yes, it seems my fix is not actually a fix when building in koji.

[David Arcari (via Email Bridge)]

From: David Arcari on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8974...

I tried Justin's patch on centos9 and it worked:

https://gitlab.com/redhat/centos-stream/src/kernel/centos-
stream-9/-/commit/3a5d7820e110ab5ac5e2ba95f7123389630e7274

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8975...

Does centos9 even need this? It wasn't required before the 5.18 merge window,
and the issues are a combination of the added features there and gcc 12
issues.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8975...

I think David is backporting patches that need it now. However, @darcari if
you're using this approach, make sure the build is using the full LDFLAGS, and
what I mean by that it should use the flags given by
```%{?build_hostldflags}```, which comes from %build_ldflags macro. This is
what I have here on a rhel9 container (should be same on centos):

```
$ rpm --eval %build_ldflags
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-
hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
$ rpm --eval %build_cflags
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64
-march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-
protection -fcf-protection
```

And you check that by adding V=1 to make command. Then you can see the gcc
flags and linker flags being given. If the build doesn't use full cflags and
ldflags (from those defined above), then we may get annocheck reports later
telling there is a problem (failing osci etc.). You'll not see it but us
maintainers can see it later...

[David Arcari (via Email Bridge)]

From: David Arcari on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8978...

That's correct - we are updating the Intel Speed Select driver and user
command in 9.1.

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8984...

I have not found a successful way to get this to build in koji without your
Makefile changes Herton. Want to send a patch upstream and create an MR to get
it in ark?

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8996...

Yes I'll try to do it here. Also, if you need to just get the build working,
feel free to keep the change on spec only not using full flags, until we get
the Makefile change upstream, I'm not against since you need to have builds
working asap.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8996...

By not using full flags I mean you can drop the %make invocation and call it
directly as a quick workaround, until we get it fixed.

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_8996...

Friday I just fixed things up by hand in dist-git, and I had planed to do the
same for rc1, but would like to just get things include-in-releases at least
until we get proper acks.

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_9002...

Justin, just opened this MR: https://gitlab.com/cki-project/kernel-
ark/-/merge_requests/1736

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_9002...

Thanks, just used that to build kernel-tools for Fedora. We do have a
different make call there though, and I had to append the include, so my lines
are:

%{tools_make} CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3"

and

%{tools_make} CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3"
DESTDIR=%{buildroot} install

[Herton R. Krzesinski (via Email Bridge)]

From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_9003...

So the problem of CFLAGS is that tools_make calls ```make CFLAGS=(...)```
instead of ```CFLAGS=(...) make```, the first form overrides the Makefile
CFLAGS and then you need to again specify the includes. We probably should
change tools_make macro, just needs to check if everything else using
tools_make still works (which I believe yes but would have to check).