Reproducer: # dnf -y builddep clufter $ mkdir -p /tmp/clufter; cd /tmp/clufter $ curl -L https://people.redhat.com/jpokorny/pkgs/clufter/clufter-0.77.1.tar.gz \ | tar xzf - $ curl -L https://pagure.io/releases/clufter/clufter-0.77.1-tests.tar.xz \ | tar xJf - $ cd clufter-0.77.1 $ python setup.py pkg_prepare --build-develop Output incl. the actual GCC comamnd: > running pkg_prepare > running build_binary > building 'ccs_flatten' extension > gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/libxml2 -I/usr/include/python2.7 -c ccs-flatten/flatten.c -o build/temp.linux-x86_64-2.7/ccs-flatten/flatten.o > {standard input}: Assembler messages: > {standard input}:7458: Error: unknown pseudo-op: `.attach_to_group' > {standard input}:7461: Error: unknown pseudo-op: `.attach_to_group' > {standard input}:7464: Error: unknown pseudo-op: `.attach_to_group' > error: command 'gcc' failed with exit status 1 When the command is taken and occurrences of > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 removed, the compilation finishes OK. * * * Content of /usr/lib/rpm/redhat/redhat-annobin-cc1: > *cc1_options: > + %{!-fno-use-annobin:%{!iplugindir*:%:find-plugindir()} -fplugin=annobin} Packages: $ rpm -q gcc annobin binutils redhat-rpm-config > gcc-8.2.1-6.fc30.x86_64 > annobin-8.65-1.fc30.x86_64 > binutils-2.31.1-17.fc30.x86_64 > redhat-rpm-config-125-1.fc30.noarch * * * Strangely, the scratch rebuild against Rawhide finished OK, the only difference seems to be redhat-rpm-config version (-126-1, not available for me directly as an update, yet), but [bug 1540971] is hardly related.
Bad results remain regardless whether "python3" is used instead or whether redhat-rpm-config is updated by hand.
Also, -fno-use-annobin is not a recognized gcc option, just tried that as a possible workaround.
Hmm, said scratch build happened to use this gcc command instead: gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -I/usr/include/libxml2 -I/usr/include/python3.7m -c ccs-flatten/flatten.c -o build/temp.linux-x86_64-3.7/ccs-flatten/flatten.o Meaning that the order of the switches is very important. I am not sure what causes it to differ, though.
... actually I know, %py3_build in spec exports some flag definitions. These may arrange the environment in the expected way. But then, out-of-package building is hopefully supported as well, still?
What's the output of “type -a ld” and “type -a ld.bfd”?
I cannot reproduce this with current rawhide. I strongly suspect you have an older binutils somewhere on your path.
Ah, thanks, mea culpa, should have occurred to me: $ type -a as > as is /usr/local/bin/as > as is /usr/bin/as $ eval /usr/{local/,}bin/as\ --version\|head\ -n1\; > GNU assembler (GNU Binutils) 2.30.0.20180207 > GNU assembler version 2.31.1-17.fc30 Forgotten remnants from some experiments with new binutils back in Feb, which explains it (mock seems to be using PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin while default environment prefers customized executables). Note sure whether there can be any better diagnostics towards users, all looks loosely coupled by design.
FWIW. I think the presence of stale binutils installation was the root cause for gdb crashing recently for me, immediately after trying to load the debug symbols. While gcc (8.2.1-6.fc30) does require binutils >= 2.31 (which is really just a soft guard as shown with this bug, raising concern whether any sort of version/capabilities matching across the players involved in the compilation is possible), gdb has no such (explicit, at least) dependency and perhaps it should if the theory that this is indeed like that (with binaries instrumented with annobin only?) is proved.
re [comment 8]: Actually, gdb case was unrelated, filed as [bug 1661199].