How do I get rid of LLVM?

[Blind_Sniper]

Hi.
Finally llvm-related software became the most bloated part of the system (apart from qt). As far as I understand llvm is just a kind of frontend to compilers, so I wondering, is it possible to get rid of this bloatware?
If there is useful info about it, please share
Thanks
_________________
GNU is Not Usable

[Hu]

You can remove it just like anything else: emerge --ask --verbose --depclean sys-devel/llvm. If it is on your system, this will probably fail with a message about some package that needs it. Add that package to the depclean list and retry. Keep growing the list until either you find a package you're not willing to remove, or you get a successful run. In some cases, packages conditionally need it based on a USE flag. If that is your situation, disabling the USE flag (and rebuilding the affected package) may let you remove LLVM without removing the consuming package. This depends on whether the USE flag controls a feature you are not willing to remove.

My guess is that you will fail, as most modern graphical desktops want Mesa, and Mesa wants LLVM, at least in the common configurations. However, some less common configurations, and anything that can remove Mesa, may not be blocked here.

[Blind_Sniper]

Thanks ofr reply!

[Hu]

LLVM is not just a compiler. Look at the list of libraries it installs. Even if it were only a compiler, if your depclean has --with-bdeps=y, then Portage would retain packages that you would need if you chose to rebuild Mesa from source.

[Blind_Sniper]

At least switching to binary mesa prevented two new huge packages from being pulled in: llvm-runtimes/compiler-rt and llvm-runtimes/compiler-rt-sanitizers.
Not bad.
_________________
GNU is Not Usable

[Anon-E-moose]

a whole 57 meg ... impressive.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[Blind_Sniper]

[Anon-E-moose]

Not to argue, but are you sure we're talking about the same packages?

[Blind_Sniper]

[logrusx]

[bstaletic]

[jesnow]

I have kind of accepted that we now have to have minimum two c/c++ compilers. But do we really have to have three slotted clangs? I don't even have a fancy system.

[logrusx]

You most definitely don't need clang:15.
What does emerge -pvc clang:15 say?
I bet you have it in world.

Best Regards,
Georgi

[Anon-E-moose]

[IP-] [ ] llvm-core/clang-15.0.7-r3:15/15g1
[IP-] [ ] llvm-core/clang-18.1.8-r6:18/18.1


So what does "emerge -pvc llvm-core/clang-15.0.7-r3" return, same for 18.1
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[jesnow]

[GDH-gentoo]

[jesnow]

The way I read this qttools hard requires 18 and everything requies qttools. So currently all my machines have to
recompile all of llvm twice. Thanks guys. some of the weaker machines my be at it for days.

Users should not be forced to have two massive C compilers on their system. But they *really* should not be forced to have three or four.

Aha: I *could* have masked off llvm/clang 19 as nothing seems to hard require it. Great.

[logrusx]

[Hu]

Since jesnow's complaint is a little unclear to me as to whom "Thanks guys" is addressing, I want to point out explicitly that Gentoo is generally limited to what upstream supports. Gentoo maintainers do not, as a general practice, create and maintain deeply invasive patches to the packages, so if upstream's qttools release only works with LLVM-18, that is what Gentoo's ebuilds will require. Unless you have specific evidence that upstream qttools has good support for LLVM-19 without serious adverse side effects to other packages on the system, please refrain from assuming the Gentoo maintainers are trying to make your life hard. I doubt they voluntarily create scenarios that force extra builds when they readily could avoid that.

[sam_]

I'll note again (as in other threads) that part of the point of the llvm-r1 eclass is to control this and not greedily pull in new slots so it's aligned to the default in profiles. Of course, sometimes software might only support an older or newer slot, and not the default one, but that's not the common case. It's hard to know what's happening for individual people here: ebuilds may still be using llvm.eclass (not everything is migrated yet, and possibly even from an overlay), or maybe the user has set custom LLVM_SLOT in /etc/portage.

(It's not clear to me if everyone in this thread even has the same problem, e.g. LLVM 19 being pulled in unnecessarily, or rather wanting everything off LLVM 18 right now, or something else). The default in eclasses is currently 19 as of about a week and a half a go, to coincide with LLVM 19 stabilisation. Some packages really don't support LLVM 19, though.

We dislike the LLVM ecosystem's issues as much as you do.

[Ionen]

[jesnow]

Thanks!

Of course the new 19 slot dropped in just when I was getting ready for this update, and dum-dee-dum-dee-dum I just let it do its thing. I should have checked more carefully.

I masked off clang-19 for the moment and all seems to be compiling well. I unmerged libreoffice but qttools seems to pull it in anyway, and mesa. I guess from wat you're saying i could put -clang and save myself the entire trouble of compiling it. But would still need llvm. I masked off version 19 of that too.

And of course clang puts max stress on my machine.

[jesnow]

Also: the switch in package category (sys-devel to llvm-core) and to a slotted package structure in a major part of the toolchain, that took me as a user by total surprise. And of course I found out the hard way, when I thought I was just updating a system, suddenly I have three slots of llvm in tree that I have to recompile, and of course it's a weak system with limited disk space, I ran out of room on root, and the whole episode cost me three days of compile time.

It's the sort of thing that ordinarily you guys issue a news item about. I'd respectfully request a heads up on such things.

Cheers,
Jon.

[Hu]

Package moves like this normally come with some metadata that causes Portage to fix up the package.* files. I remember processing one of those recently when gdb moved to dev-debug/. Did you not get such an update for LLVM? If you did get the update, what problems were caused by the category change that would have been avoided if it had remained in the old category?

[GDH-gentoo]