Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
On Tue, Nov 06, 2007 at 09:32:23AM -0800, Arjan van de Ven wrote: > On Sun, 4 Nov 2007 03:02:17 +0100 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Sat, Nov 03, 2007 at 01:11:49PM +0100, Sam Ravnborg wrote: > > > On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote: > > > > Thomas Bächler schrieb: > > > > > > > > > > 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=native -pipe". I > > > > always thought the kernel would ignore those and set its own > > > > CFLAGS, but I was wrong. Either the -O3 or the -march=native > > > > 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. > > >... > > 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... 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
On Sun, 4 Nov 2007 03:02:17 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sat, Nov 03, 2007 at 01:11:49PM +0100, Sam Ravnborg wrote: > > On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote: > > > Thomas Bächler schrieb: > > > > > > > > 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=native -pipe". I > > > always thought the kernel would ignore those and set its own > > > CFLAGS, but I was wrong. Either the -O3 or the -march=native > > > 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. > >... 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 [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Sun, 4 Nov 2007 17:34:39 +0100 > 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 > userspace software should not leak into the kernel still stands. 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Sun, 4 Nov 2007 16:29:30 +0100 > On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote: > > 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. > > Makefiles do normally not pick such variables from the environment. The absolutely do. All of the default builtin compilation rules inside of GNU make, and every other UNIX make out there, do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
Adrian Bunk wrote: On Sun, Nov 04, 2007 at 05:19:45PM +0100, Giacomo Catenazzi wrote: Adrian Bunk wrote: On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote: From: Ingo Molnar <[EMAIL PROTECTED]> Date: Sun, 4 Nov 2007 11:04:29 +0100 * Adrian Bunk <[EMAIL PROTECTED]> wrote: 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...). ... 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. 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. Makefiles do normally not pick such variables from the environment. Are you sure??? From http://www.gnu.org/software/make/manual/make.html#Environment : Variables in make can come from the environment in which make : is run. Every environment variable that make sees when it starts : up is transformed into a make variable with the same name and : value. and most important: : Thus, by setting the variable CFLAGS in your environment, you : can cause all C compilations in most makefiles to use the : compiler switches you prefer. This is safe for variables with : standard or conventional meanings because you know that no : makefile will use them for other things. (Note this is not : totally reliable; some makefiles set CFLAGS explicitly and : therefore are not affected by the value in the environment.) 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 userspace software should not leak into the kernel still stands. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
> > 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 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
On Sun, Nov 04, 2007 at 05:19:45PM +0100, Giacomo Catenazzi wrote: > Adrian Bunk wrote: >> On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote: >>> From: Ingo Molnar <[EMAIL PROTECTED]> >>> Date: Sun, 4 Nov 2007 11:04:29 +0100 >>> * Adrian Bunk <[EMAIL PROTECTED]> wrote: > 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...). >>> ... 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. >>> 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. >> Makefiles do normally not pick such variables from the environment. > > > > Are you sure??? > > From http://www.gnu.org/software/make/manual/make.html#Environment > > : Variables in make can come from the environment in which make > : is run. Every environment variable that make sees when it starts > : up is transformed into a make variable with the same name and > : value. > > and most important: > > : Thus, by setting the variable CFLAGS in your environment, you > : can cause all C compilations in most makefiles to use the > : compiler switches you prefer. This is safe for variables with > : standard or conventional meanings because you know that no > : makefile will use them for other things. (Note this is not > : totally reliable; some makefiles set CFLAGS explicitly and > : therefore are not affected by the value in the environment.) 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 userspace software should not leak into the kernel still stands. > ciao > cate 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
Adrian Bunk wrote: On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote: From: Ingo Molnar <[EMAIL PROTECTED]> Date: Sun, 4 Nov 2007 11:04:29 +0100 * Adrian Bunk <[EMAIL PROTECTED]> wrote: 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...). ... 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. 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. Makefiles do normally not pick such variables from the environment. Are you sure??? From http://www.gnu.org/software/make/manual/make.html#Environment : Variables in make can come from the environment in which make : is run. Every environment variable that make sees when it starts : up is transformed into a make variable with the same name and : value. and most important: : Thus, by setting the variable CFLAGS in your environment, you : can cause all C compilations in most makefiles to use the : compiler switches you prefer. This is safe for variables with : standard or conventional meanings because you know that no : makefile will use them for other things. (Note this is not : totally reliable; some makefiles set CFLAGS explicitly and : therefore are not affected by the value in the environment.) ciao cate - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
= 11/4/07 = > > > > 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. [] > > ... > > > At minimum the extra CFLAGS needs to be put into the .config - but > > > that's not a too nice solution either. A y/n config option to pull flags from the env? > > > 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. > > > > I totally disagree. 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`... [] > > 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 not seeing what's stupid about this. [] -- -o--=O`C #oo'L O <___=E M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote: > From: Ingo Molnar <[EMAIL PROTECTED]> > Date: Sun, 4 Nov 2007 11:04:29 +0100 > > > > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > 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...). > ... > > 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. > > 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. Makefiles do normally not pick such variables from the environment. > 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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
Sam Ravnborg schrieb: > 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 > CALLscripts/checksyscalls.sh > CC scripts/mod/empty.o I agree, this is a sane way to do it. Would this patch have been applied, I would have found the problem within minutes AND I would have known that the kernel does use my CFLAGS, which I assumed it wouldn't. Maybe you should prefix the message with a "WARNING: ". signature.asc Description: OpenPGP digital signature
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
> 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'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 CALLscripts/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)%,%,\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
From: Ingo Molnar <[EMAIL PROTECTED]> Date: Sun, 4 Nov 2007 11:04:29 +0100 > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > 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...). ... > 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. 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
On Sun, Nov 04, 2007 at 11:04:29AM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Sat, Nov 03, 2007 at 01:11:49PM +0100, Sam Ravnborg wrote: > > > On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote: > > > > Thomas Bächler schrieb: > > > > > > > > > > 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=native -pipe". I always thought the kernel would > > > > ignore those and set its own CFLAGS, but I was wrong. Either the -O3 or > > > > the -march=native 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. > > >... > > > > 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 prefix all environment variables the kernel honours with KERNEL_ ? > > 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. 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. LDFLAGS_BUILD_ID = $(patsubst -Wl$(comma)%,%,\ > > Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sat, Nov 03, 2007 at 01:11:49PM +0100, Sam Ravnborg wrote: > > On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote: > > > Thomas Bächler schrieb: > > > > > > > > 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=native -pipe". I always thought the kernel would > > > ignore those and set its own CFLAGS, but I was wrong. Either the -O3 or > > > the -march=native 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. > >... > > 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 prefix all environment variables the kernel honours with KERNEL_ ? 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
On Sat, Nov 03, 2007 at 01:11:49PM +0100, Sam Ravnborg wrote: > On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote: > > Thomas Bächler schrieb: > > > > > > 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=native -pipe". I always thought the kernel would > > ignore those and set its own CFLAGS, but I was wrong. Either the -O3 or > > the -march=native 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. >... 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 prefix all environment variables the kernel honours with KERNEL_ ? > Sam 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote: > Thomas Bächler schrieb: > > > > 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=native -pipe". I always thought the kernel would > ignore those and set its own CFLAGS, but I was wrong. Either the -O3 or > the -march=native 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
Thomas Bächler schrieb: > > 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=native -pipe". I always thought the kernel would ignore those and set its own CFLAGS, but I was wrong. Either the -O3 or the -march=native break the build process on gcc 4.2.2. signature.asc Description: OpenPGP digital signature
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
Thomas Gleixner schrieb:
> On Tue, 30 Oct 2007, Thomas Bächler wrote:
>
>> Thomas Gleixner schrieb:
>>> Thomas,
>>>
>>> On Mon, 29 Oct 2007, Thomas Bächler wrote:
x86_64 fails to compile for me with this error:
CC arch/x86/kernel/vsyscall_64.o
{standard input}: Assembler messages:
{standard input}:434: Error: symbol `vsysc2' is already defined
make[1]: *** [arch/x86/kernel/vsyscall_64.o] Error 1
make: *** [arch/x86/kernel] Error 2
The .config is attached. What's wrong?
>>> Very recent gcc I guess ? Patch below should fix this.
>> Indeed very recent. The patch doesn't solve the problem though:
>> CC arch/x86/kernel/vsyscall_64.o
>> {standard input}: Assembler messages:
>> {standard input}:436: Error: symbol `vsysc2' is already defined
>> make[1]: *** [arch/x86/kernel/vsyscall_64.o] Error 1
>> make: *** [arch/x86/kernel] Error 2
>>
>> gcc (GCC) 4.2.2
>> GNU assembler (GNU Binutils) 2.18
>
> Doh, no idea right now. Ingo has a 4.2.2 toolchain handy and will
> check tomorrow.
>
> Thanks,
>
> tglx
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
Thomas,
On Mon, 29 Oct 2007, Thomas Bächler wrote:
> x86_64 fails to compile for me with this error:
>
> CC arch/x86/kernel/vsyscall_64.o
> {standard input}: Assembler messages:
> {standard input}:434: Error: symbol `vsysc2' is already defined
> make[1]: *** [arch/x86/kernel/vsyscall_64.o] Error 1
> make: *** [arch/x86/kernel] Error 2
>
> The .config is attached. What's wrong?
Very recent gcc I guess ? Patch below should fix this.
Thanks,
tglx
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index ad4005c..1a658a2 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -102,7 +102,7 @@ static __always_inline void do_get_tz(struct timezone * tz)
static __always_inline int gettimeofday(struct timeval *tv, struct timezone
*tz)
{
int ret;
- asm volatile("vsysc2: syscall"
+ asm volatile(".globl vsysc2\n vsysc2: syscall"
: "=a" (ret)
: "0" (__NR_gettimeofday),"D" (tv),"S" (tz)
: __syscall_clobber );
@@ -112,7 +112,7 @@ static __always_inline int gettimeofday(struct timeval *tv,
struct timezone *tz)
static __always_inline long time_syscall(long *t)
{
long secs;
- asm volatile("vsysc1: syscall"
+ asm volatile(".globl vsysc1\n vsysc1: syscall"
: "=a" (secs)
: "0" (__NR_time),"D" (t) : __syscall_clobber);
return secs;
