login
Search
I just remembered, a friend of mine got it to compile with the exact same toolchain, but with a different configuration (which I don't have). He used a snapshot tarball from yesterday though, not the git tree. -
I found the problem and eliminated it. While this is my own fault, it is still a bug in either the kernel or the build system: I had CFLAGS set to "-Wall -O3 -march=3Dnative -pipe". I always thought the kernel would ignore those and set its own CFLAGS, but I was wrong. Either the -O3 or the -march=3Dnative break the build process on gcc 4.2.2.
The kernel will now honour the users CFLAGS setting as you just discovered. The flags will be appended to the flags specified by the kernel. So the kernel change is on purpose but this does not explain why it fails for you. It should be trivial to investigate which of the options that makes it fail. Sam -
I think this should be changed:
I also have CFLAGS set on some computers in my environments since for
packages using GNU autoconf that's the correct way to set the compiler
flags.
The kernel already sets all flags correctly, and a user wanting to
change the flags for the kernel is an exception with very special needs
(I'd even claim so special that he could simply edit the Makefile...).
Using the *FLAGS automatically in the kernel doesn't sound right, can we
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
this _must_ be changed before v2.6.24 is released. Thomas Bächler, Thomas Gleixner and me already wasted hours on this problem, and these kinds of issues will reoccur again and again - in perhaps even more spurious ways. Picking up randon environment details during build reduces reproducability (i couldnt reproduce the problem using the exact same toolchain) and might break various existing setups and distro builds as well. At minimum the extra CFLAGS needs to be put into the .config - but that's not a too nice solution either. How about just adding an extra-CFLAGS option to .config and perhaps a 'make configpickupCFLAGS' pass for anyone who wants to propagate the environment CFLAGS into the kernel build. Ingo -
The simpler solutions are to a) only pick up the values if specified on the make command line as in: make CFLAGS=-O3 [CFLAGS set in the environment would be ignored] b) do not pick up these variables at all c) Pick up variables with a unique name I just did c) but all three options are simple. Comments? Sam diff --git a/Makefile b/Makefile index 188c3b6..67c0639 100644 --- a/Makefile +++ b/Makefile @@ -527,10 +527,11 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,) # disable pointer signed / unsigned warnings in gcc 4.0 KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,) -# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments -KBUILD_CPPFLAGS += $(CPPFLAGS) -KBUILD_AFLAGS += $(AFLAGS) -KBUILD_CFLAGS += $(CFLAGS) +# Add user supplied KCPPFLAGS, KAFLAGS and KCFLAGS as the last assignments +# (The K prefix is added so we do not pick up often-used variables) +KBUILD_CPPFLAGS += $(KCPPFLAGS) +KBUILD_AFLAGS += $(KAFLAGS) +KBUILD_CFLAGS += $(KCFLAGS) # Use --build-id when available. -
From: Ingo Molnar <mingo@elte.hu> I totally disagree. People can't have it both ways. CFLAGS has global meaning in every Makefile based build tree, it's not an "autoconf" thing. This is well established practice, and I think it's a good thing the kernel does it now too. If people set something like CFLAGS in their environment, they must understand what that means, and it means that universally it will influence your Makefile based builds. Yes, this means all of them and even potentially the kernel build. I definitely think the new kbuild CFLAGS behavior is just fine. I would never ever set CFLAGS globally in my environment and expect sane things to happen. If people do stupid things in their environment without being willing to accept all of the consequences, that isn't a reason to not provide this feature in kbuild. Do you even understand that taking this out of kbuild will just push the problem one level of indirection away? Say this stupid CFLAGS setting creaps into someone's gcc bootstrap, and that gcc miscompiles the kernel. You will have fun debugging that too, but I'm sad to say you won't be able to pass the blame to kbuild on that one 8-/ It's just more proof that setting CFLAGS globally in your environment is just plain stupid and asking for trouble. Don't do it. -
I'm afraid some people do not realize a whit about what they do. So at least we could let kbuild warn about it. Something like this: $ export CFLAGS=-O3 $ make AFLAGS=-fisk Makefile:540: "Appending $AFLAGS (-fisk) from command line to kernel defined $AFLAGS" Makefile:544: "Appending $CFLAGS (-O3) from environment to kernel defined $CFLAGS" CHK include/linux/version.h CHK include/linux/utsrelease.h CC arch/x86/kernel/asm-offsets.s GEN include/asm-x86/asm-offsets.h CALL scripts/checksyscalls.sh CC scripts/mod/empty.o This patch is needed to do so. If one does a make O=... build then they will see the warning(s) twice. Sam diff --git a/Makefile b/Makefile index 188c3b6..1ae8779 100644 --- a/Makefile +++ b/Makefile @@ -528,9 +528,22 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,) KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,) # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments -KBUILD_CPPFLAGS += $(CPPFLAGS) -KBUILD_AFLAGS += $(AFLAGS) -KBUILD_CFLAGS += $(CFLAGS) +# But warn user when we do so +warn-assign = \ +$(warning "Appending $$$(1) ($($(1))) from $(origin $(1)) to kernel defined $$$(1)") + +ifneq ($(CPPFLAGS),) + $(call warn-assign,CPPFLAGS) + KBUILD_CPPFLAGS += $(CPPFLAGS) +endif +ifneq ($(AFLAGS),) + $(call warn-assign,AFLAGS) + KBUILD_AFLAGS += $(AFLAGS) +endif +ifneq ($(CFLAGS),) + $(call warn-assign,CFLAGS) + KBUILD_CFLAGS += $(CFLAGS) +endif # Use --build-id when available. LDFLAGS_BUILD_ID = $(patsubst -Wl$(comma)%,%,\ -
I'm not seeing what's stupid about this.
I had for years CFLAGS="-O2 -mcpu=v8" set in the environment on a
machine where I compiled virtually all software (including gcc), and
different similar settings on other machines, without running into any
problems.
I also doubt it's wanted that the kernel picks up the -I/-L/-R flags
I have set in some environments where many libraries are installed in
non-standard places.
Altogether:
- normally, Makefiles don't pick environment variables
- most open source software uses GNU autoconf
- GNU autoconf does pick environment variables
- GNU autoconf documents to set *FLAGS in the environment
- the kernel has different needs regarding the *FLAGS than userspace
- automatically using the *FLAGS people have set in their environment
for userspace software in the kernel will cause problems
- the kernel should have already picked the optimal *FLAGS for you,
and wanting different flags in the kernel is something quite exotic
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
I do too. Every ordinary (like shell, i.e. which is not setting own env program) exec*() will copy that mostly useless var for every subshell, `cat`, `cp`, `mv`... [] -- -o--=O`C #oo'L O <___=E M -
Thanks for the correction, I had forgotten about the case where a
Makefile does not set CFLAGS at all.
But the main point that stuff like e.g. -I/usr/local/dist/include that
might in some environments be correct for all and required for most
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Yes, you are right. Kernel uses the gcc in "freestanding" mode, so I think we should eventually share the compiler options and environment only with other freestanding programs (aka: none). ciao cate -
From: Adrian Bunk <bunk@kernel.org> You can have a "myconfigure" shell script that runs ./configure in the current directory with the args you want for stuff like that. There is no need to contaminate your environment by setting CFLAGS globally. -
I fully agree with David that people should realize that setting some well-known variable can affect quite a lot. But I also see that people use this for pure userspace issues. So I will shortly submit a patch to Linus that uses KCFLAGS & friends and warn if a value is picked up. Sam -
From: Adrian Bunk <bunk@kernel.org> The absolutely do. All of the default builtin compilation rules inside of GNU make, and every other UNIX make out there, do. -
On Sun, 4 Nov 2007 03:02:17 +0100 I think we can solve a ton of issues if we don't make the CFLAGS *append* but just *prepend*. That way, if the KConfig overrides a certain CFLAG, that sticks... since gcc picks the last one in case of conflicting options. That gives us both the honoring of cflags, and the principle of least surprise in that KConfig options are honored... -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org -
CFLAGS="-I/usr/include -I/usr/local/dist/include"
I think the solution with KCFLAGS that is in 2.6.24-rc2 is the best one.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-