[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230324151150.GC428955@dev-arch.thelio-3990X>
Date: Fri, 24 Mar 2023 08:11:50 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Kalle Valo <kvalo@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
dri-devel@...ts.freedesktop.org, linux-toolchains@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: Linux 6.3-rc3
On Fri, Mar 24, 2023 at 12:54:01PM +0200, Kalle Valo wrote:
> Nathan Chancellor <nathan@...nel.org> writes:
>
> > On Wed, Mar 22, 2023 at 02:44:47PM +0200, Kalle Valo wrote:
> >> Nathan Chancellor <nathan@...nel.org> writes:
> >>
> >> > Perhaps these would make doing allmodconfig builds with clang more
> >> > frequently less painful for you?
> >> >
> >> > https://lore.kernel.org/llvm/20230319235619.GA18547@dev-arch.thelio-3990X/
> >>
> >> Thank you, at least for me this is really helpful.
> >
> > Really glad to hear! I hope this helps make testing and verifying
> > changes with clang and LLVM easier for developers and maintainers.
>
> It really does. And I hope you are able to update these packages in
> future as well so that it would be easy to get the latest clang.
That is the current plan (I will push 16.0.1, 16.0.2, etc. as they are
released), I have a relatively automated process for this going forward.
> >> I tried now clang for the first time but seeing a strange problem.
> >>
> >> I prefer to define the compiler in GNUmakefile so it's easy to change
> >> compilers and I don't need to remember the exact command line. So I have
> >> this in the top level GNUmakefile (all the rest commented out):
> >>
> >> LLVM=/opt/clang/llvm-16.0.0/bin/
> >>
> >> If I run 'make oldconfig' it seems to use clang but after I run just
> >> 'make' it seems to switch back to the host GCC compiler and ask for GCC
> >> specific config questions again. Workaround for this seems to be adding
> >> 'export LLVM' to GNUmakefile, after that also 'make' uses clang as
> >> expected.
> >
> > Interesting... I just tested with a basic GNUmakefile and everything
> > seems to work fine without an export. At the same time, the export
> > should not hurt anything, so as long as it works, that is what matters.
>
> Sure, once I figured out the quirks I can workaround them. I was just
> hoping that other users would not have to go through the same hassle as
> I did :)
>
> > If you have any further issues, please do not hesitate to reach out!
>
> This is nitpicking but it would be nice if the tarball contents wouldn't
> conflict with each other. Now both llvm-16.0.0-aarch64.tar.gz and
> llvm-16.0.0-x86_64.tar extract to the same directory llvm-16.0.0 with
> same binary names. It would be much better if they would extract to
> llvm-16.0.0-aarch64 and llvm-16.0.0-x86_64, respectively.
>
> For example, Arnd's crosstool packages don't conflict with each other:
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
I could certainly do that but what is the use case for extracting both?
You cannot run the aarch64 version on an x86_64 host and vice versa, so
why bother extracting them? I had figured the architecture would be
irrelevant once installed on the host, so I opted only to include it in
the tarball name. Perhaps I should make it clearer that these are the
host architectures, not the target architectures (because clang is
multi-targeted, unlike GCC)?
> And maybe request a similar llvm directory under pub/tools to make it
> more official? :)
Yes, I was talking that over with Nick recently, as having it under a
group on kernel.org would make taking over maintainership easier should
something happen to me :)
Thanks for all the feedback so far, it is much appreciated!
Cheers,
Nathan
Powered by blists - more mailing lists