Created attachment 765141 [details] build.log Building -r2 with with Clang the new pgo use flag results in a configure error: checking for -plugin option... checking for x86_64-pc-linux-gnu-ar... (cached) llvm-ar no configure: error: AR with --plugin and rc is required for LTO build I believe this issue comes from binutils requesting a GCC LTO plugin regardless of whether Clang is used or not: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=config/gcc-plugin.m4#l139 From the above: 136 plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll" 137 plugin_option= 138 for plugin in $plugin_names; do 139 plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin` 140 if test x$plugin_so = x$plugin; then 141 plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin` 142 fi 143 if test x$plugin_so != x$plugin; then 144 plugin_option="--plugin $plugin_so" 145 break 146 fi 147 done When GCC is used as $CC in the two commands, the outputs are: telans@desktop ~ $ gcc --print-prog-name liblto_plugin.so /usr/libexec/gcc/x86_64-pc-linux-gnu/11.2.1/liblto_plugin.so telans@desktop ~ $ gcc --print-file-name liblto_plugin.so liblto_plugin.so Compared to Clang: telans@desktop ~ $ clang --print-prog-name liblto_plugin.so liblto_plugin.so telans@desktop ~ $ clang --print-file-name liblto_plugin.so liblto_plugin.so As on line 143, test is expecting a difference between the outputs which does not occur using Clang (it might be testing for the existence of the plugin). To me it seems as if that whole test and --plugin setting for AR can be avoided when using clang + lld, but I'm not sure.
Created attachment 765142 [details] emerge --info sys-devel/binutils
This issue is likely more far-reaching than merely Clang. I'm hitting a similar roadblock attempting to build binutils-2.37_p1 under GCC, which explodes catastrophically with: checking whether we are using the GNU C compiler... yes ... checking whether we are using the GNU C++ compiler... yes ... checking for -plugin option... checking for x86_64-pc-linux-gnu-ar... (cached) x86_64-pc-linux-gnu-ar x86_64-pc-linux-gnu-ar: no operation specified configure: WARNING: Failed: x86_64-pc-linux-gnu-ar --plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/10.3.0/liblto_plugin.so rc no configure: error: AR with --plugin and rc is required for LTO build This has been failing for a few weeks and is now hard-blocking other downstream packages from emerging. Welp! I'm now going to systematically disable every USE flag for "binutils" in the optimistic but unfounded hope that something will work.
Disabling the "pgo" USE flag enabled "binutils" to successfully build. Since PGO is poorly supported across both Clang and GCC, let's consider simply removing this flag until some combination of upstream and/or Gentoo-side QA can better sort out what's going on here. As always, thanks to the tireless Gentoo team for making this magic happen. \o/
(In reply to Cecil Curry from comment #3) > Disabling the "pgo" USE flag enabled "binutils" to successfully build. Since > PGO is poorly supported across both Clang and GCC, let's consider simply > removing this flag until some combination of upstream and/or Gentoo-side QA > can better sort out what's going on here. It's interesting you've hit it with GCC as I've seen no other reports of that, nor did it happen for me when I added the flag. Please include config.log & build.log of it failing with USE=pgo so we can understand what's happening.
(In reply to Sam James from comment #4) > (In reply to Cecil Curry from comment #3) > > Disabling the "pgo" USE flag enabled "binutils" to successfully build. Since > > PGO is poorly supported across both Clang and GCC, let's consider simply > > removing this flag until some combination of upstream and/or Gentoo-side QA > > can better sort out what's going on here. > > It's interesting you've hit it with GCC as I've seen no other reports of > that, nor did it happen for me when I added the flag. Please include > config.log & build.log of it failing with USE=pgo so we can understand > what's happening. I think this might be fixed by https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=268533381f80d18698fea9b15f942427f1d34cba but hard to know without log.
Created attachment 767552 [details] build.log.gz for "emerge binutils" (w/ gcc)
Created attachment 767553 [details] config.log for "emerge --info sys-devel/binutils"
Attachments are up and away. I'll submit logs straightaway the next time I want everone to believe my outlandish claims. Thanks yet again! I'm sure there's a sensible yet disconcerting reason for all of this.
(In reply to Cecil Curry from comment #7) > Created attachment 767553 [details] > config.log for "emerge --info sys-devel/binutils" That's not config.log but emerge --info. Anyway, the issue is that you have old binutils selected (and old gcc). You should be depcleaning after every world upgrade. In future, if you're hitting a bug for weeks, report it as soon as feasible so we can look at it and make sure it's not something serious. For now, you can use binutils-config and gcc-config to select the latest versions, get your world upgrade done, then depclean.
> That's not config.log but emerge --info. Insert sweat emoji here. > Anyway, the issue is that you have old binutils selected (and old gcc). *THANK YOU SO MUCH.* Sincerely appreciate you deep-diving into this, Sam. Never expected stale "eselect" entries to be the culprit... yet here we are. Would it be feasible for the "binutils" ebuild to explicitly detect and complain about this? If so, it might be useful to pluck that relatively low-hanging fruit. > You should be depcleaning after every world upgrade. Insufficient time to do so safely, sadly. I know! I know. Instead, I'll just doctor an "emerge" wrapper automatically eselecting the most recent versions of various packages I typically never think about (e.g., "binutils", "gcc", "ruby"). Thanks again, Sam. As expected, my issue was all on me. *sigh*
*ahem* Obviously, this is the wrong place for shell hackery. Nonetheless, on the offhand chance anyone else wants to automate "eselect" bumps, this Bash- and zsh-friendly shell function suffices for me: function +gentoo.bump_eselect() { (( $# == 0 )) || { echo 'Expected no arguments.' 1>&2 return 1 } echo 'Bumping "eselect" modules...' # Names of all safely bumpable "eselect" modules. local -a ESELECT_MODULE_NAMES=( binutils gcc java-vm lua ruby rust wine wxwidgets ) # For the name of each such module... local eselect_module_name eselect_module_newest for eselect_module_name in "${ESELECT_MODULE_NAMES[@]}"; do echo "Bumping \"eselect ${eselect_module_name}\" module to:" # Last "eselect" entry for this module, typically (but *NOT* # necessarily always) corresponding to the most recently installed # stable package atom for this module. This line resembles: # [4] x86_64-pc-linux-gnu-11.2.1 # # Dismantled, this is: # * "sed ...", stripping all empty lines. The output of the "list" # subcommand for most but *NOT* all "eselect" modules contains no # empty lines. Exceptions include "eselect java-vm list", which # oddly *ALWAYS* emits a trailing blank line. (It is what it is.) # * "tail ...", printing only the last line. eselect_module_newest_line="$(command eselect "${eselect_module_name}" list | \ command sed '/^$/d' | \ command tail -n 1)" echo "${eselect_module_newest_line}" # "eselect" list number parsed from this entry (e.g., "4" above). eselect_module_newest_index="$(echo "${eselect_module_newest_line}" | \ command sed -r 's~^\s*\[([[:digit:]]+)\].*$~\1~')" #FIXME: Advise users to manually set their user Java VM as well. # If this is the non-standard "eselect java-vm" module, bump only # the system Java VMs to this entry. if [[ "${eselect_module_name}" == java-vm ]]; then command eselect "${eselect_module_name}" \ set system "${eselect_module_newest_index}" # Else, bump this module to this entry. else command eselect "${eselect_module_name}" \ set "${eselect_module_newest_index}" fi done CLI output resembles: $ +gentoo.bump_eselect Bumping "eselect" modules... Bumping "eselect binutils" module to: [6] x86_64-pc-linux-gnu-2.37_p1 * * Switching to x86_64-pc-linux-gnu-2.37_p1 ...[ ok ] * Please remember to run: * # . /etc/profile Bumping "eselect gcc" module to: [4] x86_64-pc-linux-gnu-11.2.1 * * Switching native-compiler to x86_64-pc-linux-gnu-11.2.1 ...[ ok ] Bumping "eselect java-vm" module to: [3] openjdk-bin-11 system-vm Bumping "eselect lua" module to: [3] luajit-2.0.5 * Bumping "eselect ruby" module to: [2] ruby27 (with Rubygems) * Successfully switched to profile: ruby27 Bumping "eselect rust" module to: [1] rust-1.58.1 * Bumping "eselect wine" module to: [2] wine-staging-6.23 * Bumping "eselect wxwidgets" module to: [2] gtk3-unicode-3.0-gtk3 * Setting wxWidgets profile to gtk3-unicode-3.0-gtk3 Bumping shell variables... I'll show myself the door.
I guess we can close this.
