linux-kernel - Re: 2.6.24-rc1-82798a1 compile failure (x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071104.023133.241080055.davem@davemloft.net>
Date:	Sun, 04 Nov 2007 02:31:33 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	mingo@...e.hu
Cc:	bunk@...nel.org, sam@...nborg.org, thomas@...hlinux.org,
	tglx@...utronix.de, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: 2.6.24-rc1-82798a1 compile failure (x86_64)

From: Ingo Molnar <mingo@...e.hu>
Date: Sun, 4 Nov 2007 11:04:29 +0100

> 
> * Adrian Bunk <bunk@...nel.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/