Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 767700

Summary: sys-devel/lld: needs rebuild if LLVM_TARGETS on llvm changed.
Product: Gentoo Linux Reporter: Daniel Kenzelmann <gentoo>
Component: Current packagesAssignee: LLVM support project <llvm>
Status: UNCONFIRMED ---    
Severity: normal CC: 1i5t5.duncan, Adrian.Bassett, chiitoo, dan, fordfrog, gentoo-bugzilla, hjckr, hougelangley1987, ionen, matthew, mgorny, sam, simon.vanderveldt+gentoo
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=768267
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: build.log
Source of shared lib I used

Description Daniel Kenzelmann 2021-01-27 20:46:09 UTC
When trying to build www-client/firefox-85.0 with LLVM_TARGETS="BPF X86" firefox is failing.

 0:08.80 DEBUG: <truncated - see config.log for full output>
 0:08.80 DEBUG: ; return 0; }
 0:08.80 DEBUG: configure:871: checking for mingw32 environment
 0:08.80 DEBUG: configure:883: /usr/lib/llvm/11/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -c -march=native  conftest.c 1>&5
 0:08.80 DEBUG: configure:879:8: error: use of undeclared identifier '__MINGW32__'
 0:08.80 DEBUG: return __MINGW32__;
 0:08.80 DEBUG:        ^
 0:08.80 DEBUG: 1 error generated.
 0:08.81 DEBUG: configure: failed program was:
 0:08.81 DEBUG: #line 876 "configure"
 0:08.81 DEBUG: #include "confdefs.h"
 0:08.81 DEBUG:
 0:08.81 DEBUG: int main() {
 0:08.81 DEBUG: return __MINGW32__;
 0:08.81 DEBUG: ; return 0; }
 0:08.81 DEBUG: configure:902: checking for executable suffix
 0:08.81 DEBUG: configure:912: /usr/lib/llvm/11/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -o conftest -march=native  -Wl,-O1 -Wl,--as-needed -Wl,--compress-debug-sections=zlib -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld conftest.c  1>&5
 0:08.81 DEBUG: /usr/bin/ld.lld: symbol lookup error: /usr/bin/ld.lld: undefined symbol: LLVMInitializeNVPTXTargetInfo, version LLVM_11
 0:08.81 DEBUG: clang-11: error: unable to execute command: No such file or directory
 0:08.81 DEBUG: clang-11: error: linker command failed due to signal (use -v to see invocation)
 0:08.81 DEBUG: configure: error: installation or configuration problem: compiler cannot create executables.
 0:08.81 ERROR: old-configure failed


Is NVPTX required now even without any Nvidia card? If yes, please add the dependency llvm_targets_nvptx for clang (llvm_targets_NVPTX use flag for clang?) or if not make it configurable or use the LLVM_TARGETS setting.

=========
www-client/firefox-85.0:0/85::gentoo [84.0.2:0/84::gentoo] USE="clang dbus gmp-autoupdate openh264 pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp wayland -debug -eme-free -geckodriver -hardened -hwaccel -jack -lto -pgo -screencast (-selinux) -wifi" L10N="de en-GB zh-CN -ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -dsb -el -en-CA -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-TW"



Reproducible: Always




Portage 3.0.14 (python 3.8.7-final-0, default/linux/amd64/17.1/desktop/gnome/systemd, gcc-10.2.0, glibc-2.32-r7, 5.10.9-gentoo x86_64)
=================================================================
System uname: Linux-5.10.9-gentoo-x86_64-Intel-R-_Core-TM-_i5-5200U_CPU_@_2.20GHz-with-glibc2.2.5
KiB Mem:     3938688 total,    412848 free
KiB Swap:    8388604 total,   7948028 free
Timestamp of repository gentoo: Wed, 27 Jan 2021 18:30:01 +0000
Head commit of repository gentoo: 0d6568fbe59d38a855c43e1d386416fed9052f12
sh bash 5.1_p4
ld GNU ld (Gentoo 2.35.1 p2) 2.35.1
app-shells/bash:          5.1_p4::gentoo
dev-lang/perl:            5.32.0-r1::gentoo
dev-lang/python:          2.7.18-r6::gentoo, 3.8.7-r1::gentoo, 3.9.1-r1::gentoo
dev-util/cmake:           3.19.3::gentoo
sys-apps/baselayout:      2.7-r1::gentoo
sys-apps/sandbox:         2.20::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake:       1.16.3-r1::gentoo
sys-devel/binutils:       2.35.1-r1::gentoo
sys-devel/gcc:            10.2.0-r5::gentoo
sys-devel/gcc-config:     2.3.3::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.3::gentoo
sys-kernel/linux-headers: 5.10::gentoo (virtual/os-headers)
sys-libs/glibc:           2.32-r7::gentoo
Repositories:

gentoo
    location: /var/db/repos/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-verify-metamanifest: yes
    sync-rsync-verify-max-age: 24
    sync-rsync-extra-opts: 
    sync-rsync-verify-jobs: 1

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2"
DISTDIR="/var/cache/distfiles"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-march=native -O2"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-march=native -O2"
GENTOO_MIRRORS="http://mirror.eu.oneandone.net/linux/distributions/gentoo/gentoo/"
LANG="de_DE.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="de de_DE en en_GB en_US zh zh_CN"
MAKEOPTS="-j3"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cdr cli colord crypt cups dbus dri dts dvd dvdr eds emboss encode evo exif flac fortran gdbm gif gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk gui iconv icu idn introspection ipv6 jpeg lcms libglvnd libnotify libsecret libtirpc mad mng mp3 mp4 mpeg multilib nautilus ncurses networkmanager nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt5 readline sdl seccomp spell split-usr ssl startup-notification svg sysprof systemd tcpd tiff tracker truetype udev udisks unicode upower usb vorbis wayland wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" L10N="de de-DE en en-GB en-US zh zh-CN" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="BPF X86" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python2_7 python3_8" RUBY_TARGETS="ruby27" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Ionen Wolkens gentoo-dev 2021-01-27 21:09:20 UTC
I have NVPTX disabled with (X86) being the only LLVM_TARGET and 85.0 built fine for me.

Could you attach the full log? There may be more going on here.

But from what I see, it feels like your clang toolchain is broken.
Comment 2 Daniel Kenzelmann 2021-01-28 07:02:06 UTC
Created attachment 684942 [details]
build.log
Comment 3 Joonas Niilola gentoo-dev 2021-01-28 13:17:24 UTC
Can you please show:
$ emerge -pv --nodeps llvm rust clang
Comment 4 Daniel Kenzelmann 2021-01-28 13:24:38 UTC
# emerge -pv --nodeps llvm rust clang

These are the packages that would be merged, in order:

[ebuild   R    ] sys-devel/llvm-11.0.1:11::gentoo  USE="libffi ncurses xml -debug -doc -exegesis -gold -libedit -test -xar -z3" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="BPF (X86) -AArch64 -AMDGPU (-ARC) -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ (-VE) -WebAssembly -XCore" 0 KiB
[ebuild   R    ] dev-lang/rust-1.48.0:stable/1.48::gentoo  USE="-clippy -debug (-doc) -libressl (-miri) -nightly -parallel-compiler -rls -rustfmt -system-bootstrap -system-llvm -test -wasm" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_TARGETS="BPF (X86) -AArch64 -AMDGPU -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 0 KiB
[ebuild   R    ] sys-devel/clang-11.0.1:11::gentoo  USE="static-analyzer xml -debug -default-compiler-rt -default-libcxx -default-lld -doc -test" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="BPF (X86) -AArch64 -AMDGPU (-ARC) -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ (-VE) -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_8 -python3_7 -python3_9" 0 KiB

Total: 3 packages (3 reinstalls), Size of downloads: 0 KiB
Comment 5 Ionen Wolkens gentoo-dev 2021-01-28 13:48:07 UTC
Can you try to rebuild lld? I'd like to think that it doesn't need to be rebuilt on target changes, but it's the impression I'm getting here.

emerge -1 sys-devel/lld
Comment 6 Daniel Kenzelmann 2021-01-28 13:59:11 UTC
That seemed to do the trick, firefox is compiling now :)
Thanks!
Comment 7 Ionen Wolkens gentoo-dev 2021-01-28 14:13:01 UTC
Glad to hear :)

Tried to reproduce meanwhile, and sure enough:

$ strings /usr/bin/ld.lld | grep 'LLVMInitialize.*TargetInfo'
LLVMInitializeNVPTXTargetInfo
LLVMInitializeX86TargetInfo

After rebuilding llvm without NVPTX:

$ clang -fuse-ld=lld -o hello hello.c
/usr/bin/ld.lld: symbol lookup error: /usr/bin/ld.lld: undefined symbol: LLVMInitializeNVPTXTargetInfo, version LLVM_11
clang-11: error: unable to execute command: No such file or directory
clang-11: error: linker command failed due to signal (use -v to see invocation)
Comment 8 Ionen Wolkens gentoo-dev 2021-01-28 14:34:56 UTC
My personal opinion, to avoid failure on a system which defaults to lld and would have trouble rebuilding lld with lld, would be that sys-devel/lld shouldn't be a separate package. Unless there's some other way to deal with this.
Comment 9 Ionen Wolkens gentoo-dev 2021-02-05 20:57:54 UTC
*** Bug 768900 has been marked as a duplicate of this bug. ***
Comment 10 jospezial 2021-02-19 20:13:36 UTC
Maybe we should add LLVM_TARGETS to lld?
Then lld would be rebuilt.
And nobody should change LLVM_TARGETS for sys-devel/llvm only.
Comment 11 Ionen Wolkens gentoo-dev 2021-02-19 20:31:10 UTC
(In reply to jospezial from comment #10)
> Maybe we should add LLVM_TARGETS to lld?
> Then lld would be rebuilt.
> And nobody should change LLVM_TARGETS for sys-devel/llvm only.
While it would reduce issues, I find it unfortunate this would lock out of rebuilding lld with lld, e.g. have to link with ld.bfd/gold given ld.lld is broken.

Optimally it would be nice if clang/lld were never in a broken state because another component changed, much like wouldn't want that to happen to gcc/binutils.
Comment 12 Ionen Wolkens gentoo-dev 2021-02-19 20:37:47 UTC
(In reply to Ionen Wolkens from comment #11)
> Optimally it would be nice if clang/lld were never in a broken state because
> another component changed.
And if abi issues can't be avoided and rebuilds are necessary, the only real solution I see to this is for llvm to not be a split package.

But some simpler solution to ensure lld is rebuilt meanwhile wouldn't hurt.
Comment 13 Nikolay Kichukov 2021-09-10 08:30:50 UTC
I've added new arches to LLVM_TARGETS and removed BPF from there and then tried to recompile 'clang'.

Once llvm got updated and had BPF removed, clang would no longer compile.

I've tried to recompile the linker lld, but no luck there either. 

I've tried to recompile clang/lld with gcc, but this was not successful either.

How is one supposed to be able to remove 'BPF' from existing clang/llvm install?

llvm-12.0.1
clang-12.0.1
lld-12.0.1

I had to deploy a binary package of llvm that had +BPF target to be able to restore the toolchain.

In the end, I've added the new arches to the targets leaving BPF in the list:

$ emerge -pv --nodeps clang rust llvm

These are the packages that would be merged, in order:

[ebuild   R    ] sys-devel/clang-12.0.1:12::gentoo  USE="default-compiler-rt default-libcxx default-lld llvm-libunwind static-analyzer -debug -doc -test -xml" LLVM_TARGETS="AArch64* ARM* BPF (X86) -AMDGPU -ARC -AVR (-CSKY) -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -VE -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_9 (-python3_10) -python3_8" 0 KiB
[ebuild  N     ] dev-lang/rust-1.53.0:stable/1.53::gentoo  USE="-clippy -debug -doc (-miri) (-nightly) (-parallel-compiler) -rls -rustfmt (-system-bootstrap) (-system-llvm) -test -verify-sig -wasm" CPU_FLAGS_X86="sse2" LLVM_TARGETS="AArch64 ARM BPF (X86) -AMDGPU -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 252676 KiB
[ebuild   R    ] sys-devel/llvm-12.0.1:12::gentoo  USE="libffi ncurses -debug -doc -exegesis -gold -libedit -test -xar -xml -z3" LLVM_TARGETS="AArch64* ARM* BPF (X86) -AMDGPU -ARC -AVR (-CSKY) -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -VE -WebAssembly -XCore" 0 KiB
Comment 14 Scott Howard 2021-09-25 18:47:20 UTC
I have the same question as the previous comment, and more information to add.

I previously had LLVM_TARGETS='*', but the VE and ARC targets were recently masked on my arch (ppc64).

So llvm was rebuilt first, and then clang. The /usr/lib/llvm/12/lib64/libLLVM-12.so object was rebuilt without symbols like LLVMInitializeVETargetInfo, but clang still had references to these:

$ strings /usr/lib/llvm/12/bin/clang | grep LLVMInitializeVETargetInfo
LLVMInitializeVETargetInfo

So when clang runs during the clang rebuild, it is broken:

clang: symbol lookup error: clang: undefined symbol: LLVMInitializeVETargetInfo, version LLVM_12

----

I restored the LLVM_TARGETS and rebuilt llvm, but clang still has the references to the old symbols:

[ebuild   R    ] sys-devel/clang-12.0.1:12::gentoo  USE="static-analyzer -debug -default-compiler-rt (-default-libcxx) -default-lld -doc -llvm-libunwind -test -xml" LLVM_TARGETS="AArch64 ARM AVR BPF (PowerPC) RISCV SystemZ WebAssembly X86 -AMDGPU (-ARC) (-CSKY) -Hexagon -Lanai -MSP430 -Mips -NVPTX -Sparc (-VE) -XCore" PYTHON_SINGLE_TARGET="python3_9 (-python3_10) -python3_8" 0 KiB

$ strings /usr/lib/llvm/12/bin/clang | grep LLVMInitializeVETargetInfo
LLVMInitializeVETargetInfo

----

How do I rebuild clang to remove these symbols?
Comment 15 Miroslav Šulc gentoo-dev 2021-10-12 13:08:05 UTC
in my case, i put LLVM_TARGETS="NVPTX" in /etc/portage/make.conf and since then i was not able to compile (configure) firefox nor thunderbird, it ended up with this error:

 0:02.10 checking for linker...
 0:02.10 DEBUG: Executing: `/usr/lib/llvm/12/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -fuse-ld=lld -Wl,--version`
 0:02.10 ERROR: Could not use lld as linker

after re-emerging lld the configuration does not fail anymore. tested on two machines with nvidia gpu.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-10-13 15:34:08 UTC
I've tried addressing this a few times and couldn't figure out a good way to make lld (or even clang, tbh) respect LLVM_TARGETS fully without copying the initializers from LLVM itself.  To be honest, at this point I'm considering use.forcing all (non-masked) targets for the time being.  While this is far from a perfect solution and has an inevitable cost in build time, it should at least prevent non-expert users from breaking their systems and give a fair warning to expert users.
Comment 17 SpanKY gentoo-dev 2021-11-03 16:44:20 UTC
*** Bug 821436 has been marked as a duplicate of this bug. ***
Comment 18 François-Xavier Carton 2022-01-31 23:53:56 UTC
Created attachment 764063 [details]
Source of shared lib I used

clang and rust also have this problem. I wanted to remove the extra ARM targets I had on llvm (only, not clang/rust) on a amd64 system, so I rebuild llvm without it. Then, clang and rust would complain about missing initialization symbols for ARM. For rust, it's especially tricky if one wants to use system-bootstrap, as it needs a working rust.

I solved this by reinstalling rust with LD_PRELOAD set to a small shared library containing the missing symbols (I'm attaching the source). It's ugly, but allowed reinstalling rust keeping system-bootstrap.

Could a solution be to always define the missing symbols, which would do nothing if the target isn't there?
Comment 19 Duncan 2022-02-08 06:58:52 UTC
Maybe a news item when use.forcing a bunch of exotic stuff like that next time?  It's not like we all have that $10K+ threadripper I've been begging Santa for after all.[1]
 
I ended up profile/use.mask-ing everything I didn't need and have set already for the older versions (with a comment referencing this bug) as the llvm-13.0.1 update was taking /forever/ building exotic targets like sparc and hexagon that I haven't even the /slightest/ interest in.

---
[1] Maybe after the car is paid off later this year I can /think/ about upgrading my decade-old 6-core fx6100 bulldozer-1 hardware... still unlikely to the $10k+ 64-core/128-thread threadripper w/ 256G RAM for all those threads to play, but one can dream...
Comment 20 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-02-08 07:00:45 UTC
(In reply to Duncan from comment #19)
> Maybe a news item when use.forcing a bunch of exotic stuff like that next
> time?  It's not like we all have that $10K+ threadripper I've been begging
> Santa for after all.[1]
>  
> I ended up profile/use.mask-ing everything I didn't need and have set
> already for the older versions (with a comment referencing this bug) as the
> llvm-13.0.1 update was taking /forever/ building exotic targets like sparc
> and hexagon that I haven't even the /slightest/ interest in.

Please do try leave the snark out of it. As you can see in this bug, it's not really (sadly) about whether people are interested in random targets, but about how fragile Rust and other consumers are (like LLD) when the targets are changed at all, and in fact, surprisingly, some things like Zig *need* all targets on.

We tend to prefer news items when there's something actionable and in this case, for most people, they _shouldn't_ do anything for the aforementioned reasons. But yes, maybe it would've been useful for informative purposes.
Comment 21 Nikolay Kichukov 2022-03-08 08:47:45 UTC
(In reply to Duncan from comment #19)
...snip...
> I ended up profile/use.mask-ing everything I didn't need and have set
> already for the older versions (with a comment referencing this bug) as the
> llvm-13.0.1 update was taking /forever/ building exotic targets like sparc
> and hexagon that I haven't even the /slightest/ interest in.
...snip...

I have ended up doing the same thing when I noticed all these arches will get compiled in with the upgrade to clang/llvm version 13.0.1. 

And I do not understand why this so is. Why did portage suddenly stop respecting LLVM_TARGETS from make.conf and bundled it all together? This is not a one size fits all distribution...
Comment 22 Duncan 2022-03-08 10:04:27 UTC
(In reply to Nikolay Kichukov from comment #21)
> And I do not understand why this so is. Why did portage suddenly stop
> respecting LLVM_TARGETS from make.conf and bundled it all together?

That's the power of use.force at the profile level, tho it's normally used far more "surgically" than this, with the contrast to normal what makes this so shocking. That said...

> This is not a one size fits all distribution...

It's supposed to be a temporary fix.  I understand (at a high level) why they did it and could imagine myself taking a similar approach to the problem while working on something better, but a warning (such as the news item I suggested) would have been appreciated, precisely for the reason you mentioned -- this is /not/ (normally) a one-size-fits-all distro.

Luckily for us, by the same token, gentoo policy is to always provide user overrides for such things, with the result being gentoo's flexibility and ability to do and be used for all sorts of things normal distros can't, at least without far more invasive tweaking.
Comment 23 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-08 10:12:44 UTC
I'm fine with us having a pkg_postinst comparison with saved LLVM_TARGETS in pkg_preinst and warning if they differ.
Comment 24 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-08 10:50:41 UTC
(In reply to Sam James from comment #23)
> I'm fine with us having a pkg_postinst comparison with saved LLVM_TARGETS in
> pkg_preinst and warning if they differ.

(I don't have time to do this today or any time very soon as mgorny's PSU has died, please share an implementation even as a draft if you want this.)
Comment 25 Simon 2022-03-16 21:12:31 UTC
I'm probably missing something obvious, but can't lld just depend on LLVM in such a way that it always gets rebuilt in case LLVM gets rebuilt or when LLVM's USE flags change?
Comment 26 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2022-03-16 21:54:35 UTC
No, not really.  The closest thing is "=" USE-dep but that would just give user annoying errors when USE flags mismatch between LLVM and LLD.
Comment 27 Ionen Wolkens gentoo-dev 2022-03-16 23:14:17 UTC
Doesn't help that these tools should ideally be able to rebuild themselves and not be in an intermediary broken state that require gcc/ld.bfd to build again. I don't think juggling rebuilds is going to work out on the long run.

Even rebuild order matters (e.g. LLVM_TARGETS --changed/new-use rebuilds doesn't always save clang from breakage).