Bug 1660854 - gcc -specs=redhat-annobin-cc1 causes failure: Assembler messages: Error: unknown pseudo-op: `.attach_to_group'
Summary: gcc -specs=redhat-annobin-cc1 causes failure: Assembler messages: Error: unkn...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: annobin
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-19 11:57 UTC by Jan Pokorný [poki]
Modified: 2019-04-24 10:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-24 10:42:39 UTC


Attachments (Terms of Use)

Description Jan Pokorný [poki] 2018-12-19 11:57:25 UTC
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.

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

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


Note You need to log in before you can comment on or make changes to this bug.