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: | annobin | Assignee: | Nick Clifton <nickc> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | fweimer, jpokorny, nickc, riehecky |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | |
| Embargoed: | |||
|
Description
Jan Pokorný [poki]
2018-12-19 11:57:25 UTC
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]. |