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
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.
Created attachment 684942 [details] build.log
Can you please show: $ emerge -pv --nodeps llvm rust clang
# 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
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
That seemed to do the trick, firefox is compiling now :) Thanks!
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)
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.
*** Bug 768900 has been marked as a duplicate of this bug. ***
Maybe we should add LLVM_TARGETS to lld? Then lld would be rebuilt. And nobody should change LLVM_TARGETS for sys-devel/llvm only.
(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.
(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.
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
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?
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.
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.
*** Bug 821436 has been marked as a duplicate of this bug. ***
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?
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...
(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.
(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...
(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.
I'm fine with us having a pkg_postinst comparison with saved LLVM_TARGETS in pkg_preinst and warning if they differ.
(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.)
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?
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.
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).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=698ec80663c740fa7b03ec11821bfd7189d10bf5 commit 698ec80663c740fa7b03ec11821bfd7189d10bf5 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-26 02:12:19 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-26 02:12:19 +0000 profiles/base: add bug ref to LLVM_TARGETS force Bug: https://bugs.gentoo.org/767700 Signed-off-by: Sam James <sam@gentoo.org> profiles/base/package.use.force | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
