Should I live with bleeding-edge LLVM?

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2170

I suspect the answer is no, but first some background:
My system is configured to use the LLVM/Clang toolchain (except where either the ebuilds override, or where I've hit a problem and reverted to gcc), and it's all OK.
I compile my kernels using the latest stable source from kernel.org, rather than using gentoo-sources or any of the newer Gentoo options.
And to add excitement, I compile the kernels with "KCFLAGS='-march=native'". Still (mostly) OK.

The bit that's now not OK is that the kernel compilation fails with Clang:18, and produces a nice message asking me to report a bug to the LLVM developers, which I did. They tell me the cure (I bet you were expecting this) is to upgrade to version 19. That's in portage, but keyworded out of visibility unless you add a file overrides to portage.accept_keywords and edit it to replace 18-foo with 19-bah.
Installing that, and then remembering to "source /etc/profile" meant that I could now build my kernel OK. So I'm a happy bunny, except with two issues:

1) Am I correct in thinking portage just uses the current toolchain, so if I were to run "emerge --update", I'd now be compiling with LLVM:19, and this might be brave, or exciting, or other synonyms for stupid :-)

2) While I note there are now three 60llvm-foo files in /etc/env.d, which select slot 17, 18 and 19 versions, there seems to be neither "eselect llvm" nor "llvm-config" (or rather not one that's equivalent to gcc-config) to manage them. Am I missing a switch?

Of course, I could just trust the LLVM guys and run 19.1.0.
_________________
Greybeard

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2380

Zucca · Posted: Fri Aug 02, 2024 8:35 pm Post subject:

I feel like there's a need for llvm eselect module...
_________________
..: Zucca :..

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2380

Zucca · Posted: Sat Aug 03, 2024 7:16 am Post subject:

It would look like modifying llvm related files under /etc/env.d/ and then running env-update you could possibly change the default llvm being used.
I've only played around with one llvm toolchain system... So, I have very little experience on this.

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2380

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2170

You're right, bleeding-edge is 9999, and 19 is mainstream. And presumably there's no "eselect llvm" because there's no need, as it's a pretty solid toolchain.
Though :19 has yet to reach even ~amd86, I may just leave it, or maybe write my own "eselect llvm", which probably create a private /etc/env,d/65llvm-bloody, run env-update and issue a large reminder to restart terminal windows/reboot to taste.
_________________
Greybeard

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2380

I guess if eselect llvm clang appears, then the should be eselect compiler or something and it'll be a huge mess.

Zucca · Posted: Sat Aug 03, 2024 1:36 pm Post subject:

Ralphred · l33t Joined: 31 Dec 2013 Posts: 638

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2170

As I use a binpkg server, I have both :18 and :19 on the shelf. :smug:
_________________
Greybeard

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2170

<edit>Whoops, "llvm-config" already exists, and does complex stuff, and is part of llvm.
So I'll rename my script to "config-llvm", though maybe it ought to be a "llvm.eselect" module.
</edit>

For anyone who wants an alpha-release config-llvm, here's my quick-and-dirty version.
It manages a symlink "60llvm-0000", which will sort before any of the other "60llvm-<foo>" profiles.

It ought to issue "env-update" and a warning saying to ". /etc/profile' when necessary, but it doesn't.

Comparing it with gcc-config just makes me feel well inadequate :-)