Bug 1660854

Summary: gcc -specs=redhat-annobin-cc1 causes failure: Assembler messages: Error: unknown pseudo-op: `.attach_to_group'
Product: [Fedora] Fedora Reporter: Jan Pokorný [poki] <jpokorny>
Component: annobinAssignee: Nick Clifton <nickc>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: fweimer, jpokorny, nickc, riehecky
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-24 10:42:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jan Pokorný [poki] 2018-12-19 11:57:25 UTC

# 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}


$ 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.

Comment 1 Jan Pokorný [poki] 2018-12-19 12:00:57 UTC
Bad results remain regardless whether "python3" is used instead
or whether redhat-rpm-config is updated by hand.

Comment 2 Jan Pokorný [poki] 2018-12-19 12:05:35 UTC
Also, -fno-use-annobin is not a recognized gcc option, just tried that
as a possible workaround.

Comment 3 Jan Pokorný [poki] 2018-12-19 12:11:01 UTC
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.

Comment 4 Jan Pokorný [poki] 2018-12-19 12:14:27 UTC
... 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?

Comment 5 Florian Weimer 2018-12-19 13:26:16 UTC
What's the output of “type -a ld” and “type -a ld.bfd”?

Comment 6 Florian Weimer 2018-12-19 13:31:13 UTC
I cannot reproduce this with current rawhide.  I strongly suspect you have an older binutils somewhere on your path.

Comment 7 Jan Pokorný [poki] 2018-12-19 14:06:57 UTC
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)
> 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.

Comment 8 Jan Pokorný [poki] 2018-12-20 11:11:09 UTC
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.

Comment 9 Jan Pokorný [poki] 2018-12-20 11:50:17 UTC
re [comment 8]:

Actually, gdb case was unrelated, filed as [bug 1661199].