Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 22 Jun 2022 11:21:09 -0500 | Subject | Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support") |
| |
On Wed, Jun 22, 2022 at 10:02 AM Nathan Chancellor <nathan@kernel.org> wrote: > > Right, we are working on a statically linked and optimized build of LLVM > that people can use similar to the GCC builds provided on kernel.org, > which should make the compile time problem not as bad as well as making > it easier for developers to get access to a recent version of clang with > all the fixes and improvements that we have made in upstream LLVM.
So I'm on the road, and will try to see how well I can do that allmodconfig build on my poor laptop and see what else goes wrong for now.
But I do have to say that it's just a lot better if the regular distro compiler build works out of the box. I did build my own clang binary for a while, just because I was an early adopter of the whole "ask goto with outputs" thing, but I've been *so* much happier now that I don't need to do that any more.
So I would prefer not going backwards.
I wish the standard clang build just stopped doing the crazy shared library thing. The security arguments for it are just ridiculous, when any shared library update for any security reason would mean a full clang update _anyway_.
I realize it's partly distro rules too, but the distros only do that "we always build shared libraries" when the project itself makes that an option. And it's a really stupid option for the regular C compiler case.
Side note: I think gcc takes almost exactly the opposite approach, and does much better as a result. It doesn't do a shared libary, but what it *does* do is make 'gcc' itself a reasonably small binary that just does the command line front-end parsing.
The advantage of the gcc model is that it works *really* well for the "test compiler options" kind of stage, where you only run that much simpler 'gcc' wrapper binary.
We don't actually take full advantage of that, because we do end up doing a real "build" of an empty file, so "cc1" does actually get executed, but even then it's done fairly efficiently with 'vfork()'. That "cc-option" part of the kernel build is actually noticeable during configuration etc, and clang is *much* slower because of how it is built.
See
time clang -Werror -c -x c /dev/null
and compare it with gcc. And if you want to see a really *big* difference, pick a command line option that causes an error because it doesn't exist..
I really wish clang wasn't so much noticeably slower. It's limiting what I do with it, and I've had other developers say the same.
Linus
| |