[solved] LLVM_TARGETS not respected?

[smartding]

I have LLVM_TARGETS="X86 BPF" in my /etc/portage/make.conf

Today, after upgrading to llvm 13.0.1, running llc --version shows:

[Ionen]

Given disabling targets breaks ABI, they're now forced by default as a precaution (i.e. could break clang/rust/lld and -U/-N to force rebuild on LLVM_TARGETS changes doesn't always work out so well). Packages like zig also need all targets enabled and don't support these being arbitrarily disabled.

If you /really/ want to disable them, you'll need to unforce it through /etc/portage/profile/package.use.force by adding e.g. */* -llvm_targets_AArch64 and so on at your own risks (will at least need to ensure clang was rebuilt after llvm -- if before it'll be broken, and manually rebuild lld -- if using system-llvm on rust it'll likely be broken too if rebuilt before, any other package using llvm libraries may also have problems even if they don't use LLVM_TARGETS at all).

[Hu]

Ionen addressed the immediate problem. As a general tip, when reporting that flags are not what you want, you should show the Portage output confirming that. In this case, emerge --verbose --info sys-devel/llvm would have been nice to have.

[sdauth]

Thanks Ionen for the explanation. I was having the same issue as OP. It would be nice to add a note to eselect news to warn users about it.

[figueroa]

+1 -- I came here this morning specifically looking for this thread.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

[dmpogo]

Same as other people, a bit froze seeing all the targets in the today's update

[Ionen]

[dmpogo]

[smartding]

Mystery solved.

It would be better if there's some info about this change at the end of emerge.

[Hu]

I would think that most people who notice this at all would notice it before building LLVM, so a notice logged at the end of the llvm emerge would be too late. As I hinted above, the output of emerge --pretend --verbose should show the flags as forced.

[nagora]

Yeah, mystery solved but what a terrible solution! And a huge waste of electricity and processing time compiling targets that I will never use or need.

So, does LLVM_TARGETS just do nothing now?

[Hu]

As Ionen described, this was an unfortunate necessity due to other packages breaking in response to custom LLVM_TARGETS values. If those breaks were fixed, the flag could probably be made tunable again.

[sam_]

[figueroa]

Sam, how about: "To prevent breakage of other core packages, a change has been made to now stable sys-devel/llvm- 13.0.1 to force ON all LLVM_TARGETS. Users' custom LLVM_TARGETS are ignored. No action is required on the part of the user. For further information, users may refer to the discussion in the following forum thread:
https://forums.gentoo.org/viewtopic.php?p=8694331
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

[xavier10]

Useful discussion, I was looking just for this information.

I was looking for ideas to cut down llvm/clang compilation time and initially thought reducing the list of targets might be a good idea, but I see it is not; is there any other way to reduce the emerge time that I could pursue ?

[rogge]

Thanks a lot for explanation!

[njsg]

Is rust-bin also affected by this ABI incompatibility?

[RIA77]

Why there is no LLM targets respected ? I have still the same problem.

[Hu]

[Ionen]

Can note that the ABI issues are still valid today and people that un-force LLVM_TARGETS sometime still end up with a broken llvm toolchain (incl. rust if USE=system-llvm) depending on ordering, not that this is a problem if you can fallback to gcc+binutils and rebuild the broken bits (doing this on a llvm profile without gcc could lead to a broken system that will need binpkgs to recover).

If toolchain is broken, it will manifest itself as undefined symbols in clang or lld themselves, and things like firefox[clang] will fail to build. You just need to rebuild lld and clang in that situation, and maybe rust.

But after that's sorted, it should never come back as an issue and you can safely enjoy quicker llvm builds (fine to have less targets on rust too, or USE=system-llvm is fine as well after it is rebuilt -- albeit may as well use rust-bin if goal is to shorten build time)

If understand the risks and in case process is still not clear -- essentially need to revert what /var/db/repos/gentoo/profiles/base/package.use.force does for llvm targets which can be done using /etc/portage/profile/package.use.force (note that this is under the profile/ directory, not top level), aka with:

[RIA77]