From: Herton R. Krzesinski on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1721#note_895271798 > > > > CKI Gitlab commented: > > > DJ Delorie <dj@xxxxxxxxxx> commented via email: > ``` > Prarit Bhargava <prarit@xxxxxxxxxx> 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. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
