Description of problem: strip:revd[.gnu.build.attributes]: corrupt GNU build attribute note: wrong note type: bad value Version-Release number of selected component (if applicable): gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1) GNU strip version 2.32-26.fc31 How reproducible: gcc *.c, strip <binary> Steps to Reproduce: 1. gcc -g *.c 2. strip <binary> 3. Actual results: strip:revd[.gnu.build.attributes]: corrupt GNU build attribute note: wrong note type: bad value Expected results: no error Additional info:
That would be either annobin or binutils bug, but guess you need to specify details, on what exactly you are compiling and annobin version.
'guess you need to specify details, on what exactly you are compiling and annobin version.' Name : annobin Version : 8.78 Release : 2.fc31 Architecture : x86_64 Name : binutils Version : 2.32 Release : 26.fc31 Architecture : x86_64 as I installed gdb a couple of days ago: Name : gdb Version : 8.3.50.20190824 Release : 24.fc31 Architecture : x86_64 rev.c a simple program with only 60 LOC, CFLAGS=-g -DDEBUG -Wall -Wshadow. For our purposes II written some #include <stdio.h> /* puts */ int main ( int argc, char* argv[] ){ puts ("Hello World!"); return 0; } invoked gcc -g hello.c then strip a.out resulting in --> strip:a.out[.gnu.build.attributes]: corrupt GNU build attribute note: wrong note type: bad value
I'm seeing this problem when after building firefox nightly. When I install, this error occurs when the binaries are stripped. 0:00.58 /usr/bin/gmake -C . -j6 -s -w install 0:00.60 gmake: Entering directory '/mnt/to_archive/accum/src/firefox-source/obj-x86_64-pc-linux-gnu' 0:00.61 gmake[1]: Entering directory '/mnt/to_archive/accum/src/firefox-source/obj-x86_64-pc-linux-gnu/browser/installer' 0:06.06 strip:../../dist/firefox/libnspr4.so[.gnu.build.attributes]: corrupt GNU build attribute note: wrong note type: bad value 0:06.06 Traceback (most recent call last): 0:06.06 File "/mnt/to_archive/accum/src/firefox-source/toolkit/mozapps/installer/packager.py", line 339, in <module> 0:06.06 main() 0:06.06 File "/mnt/to_archive/accum/src/firefox-source/toolkit/mozapps/installer/packager.py", line 333, in main 0:06.06 copier.copy(args.destination) 0:06.06 File "/mnt/to_archive/accum/src/firefox-source/python/mozbuild/mozpack/copier.py", line 432, in copy 0:06.06 copy_results.append((destfile, f.copy(destfile, skip_if_older))) 0:06.06 File "/mnt/to_archive/accum/src/firefox-source/python/mozbuild/mozpack/files.py", line 320, in copy 0:06.06 strip(dest) 0:06.06 File "/mnt/to_archive/accum/src/firefox-source/python/mozbuild/mozpack/executables.py", line 101, in strip 0:06.06 errors.fatal('Error executing ' + ' '.join(cmd)) 0:06.06 File "/mnt/to_archive/accum/src/firefox-source/python/mozbuild/mozpack/errors.py", line 103, in fatal 0:06.06 self._handle(self.FATAL, msg) 0:06.06 File "/mnt/to_archive/accum/src/firefox-source/python/mozbuild/mozpack/errors.py", line 98, in _handle 0:06.06 raise ErrorMessage(msg) 0:06.06 mozpack.errors.ErrorMessage: Error: Error executing strip --strip-debug ../../dist/firefox/libnspr4.so 0:06.10 gmake[1]: *** [/mnt/to_archive/accum/src/firefox-source/toolkit/mozapps/installer/packager.mk:25: stage-package] Error 1 0:06.10 gmake[1]: Leaving directory '/mnt/to_archive/accum/src/firefox-source/obj-x86_64-pc-linux-gnu/browser/installer' 0:06.10 gmake: *** [/mnt/to_archive/accum/src/firefox-source/browser/build.mk:15: install] Error 2 0:06.10 gmake: Leaving directory '/mnt/to_archive/accum/src/firefox-source/obj-x86_64-pc-linux-gnu'
I also faced this issue on only f31, and reported it to binutils: strip here. https://bugzilla.redhat.com/show_bug.cgi?id=1770464#c10
I'm not sure if this is hitting f32/rawhide as well, but rawhide composes have failed in recent days due to size issues. The armv7 Xfce image was 100MB larger, and the kde live is now showing about 238MB larger. ;(
Following the advice in the bugzilla that Jun Aruga pointed to in a different way, I went to https://koji.fedoraproject.org/koji/buildinfo?buildID=1415570 and downloaded the updated F31 binutils packages that I have installed on my system. I then used dnf -C update [package names] to update them and my problem with stripping went away. So, a workaround until those packages make it into the repositories.
Hi Everyone, > Description of problem: > strip:revd[.gnu.build.attributes]: corrupt GNU build attribute note: wrong > note type: bad value Sorry about this. This is caused by a bug in the strip program which was corrupting annobin data. If you upgrade to one of the 2.33-8.fc32, 2.32-29.fc31 or 2.31.1-36.fc30 binutils releases the problem should go away. Cheers Nick
it's fixed with todays binutils update. Hence I'm closing it. Thanks again RH people!
Resolution should be ERRATA, then, not NOTABUG.
does this means that i need to wait mass rebuild? (i'm user of coreos/rpm-ostree and compose my own trees)
I'm looking into it. I would think we'd need to rebuild everything built while the bad binutils was in place, but so far it doesn't *seem* to be that simple...
> If you upgrade to one of the 2.33-8.fc32, 2.32-29.fc31 or 2.31.1-36.fc30 binutils releases the problem should go away. Are you sure all issues are fixed? Indeed, the obvious failure message from strip is gone, however it seems something is still broken. On Fedora 31, I installed binutils and binutils-gold 2.32-29.fc31. When issuing `fedpkg local` from NetworkManager, the resulting libnm.so.0.1.0 is significantly larger than it should be, and `readelf --notes --wide /usr/lib64/libnm.so.0.1.0` shows log of bogus notes. For details, see my email from the mailing list https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CSQJUY7XKTKMPXZEMXF4WNNFHBS7O6MP/
(In reply to Thomas Haller from comment #12) Hi Thomas, > Are you sure all issues are fixed? Yes and no. > When issuing `fedpkg local` from NetworkManager, the resulting > libnm.so.0.1.0 is significantly larger than it should be, and `readelf What has happened is that strip is no longer compressing the notes by default. This is because the corrupted notes are still present in the system - most notably in glibc's crti.o and crtn.o files. This means that strip is unable to compress the notes in files that have been linked with these files. (Or any other files containing corrupted notes). But - once a mass rebuild has completed, it will be safe to re-enable note compression in strip. In the meantime you can, if you wish, use the objcopy program to completely remove the note section, thus saving a lot of space. objcopy --remove-section=.gnu.buld.attributes libnm.so.0.1.0 Cheers Nick
(In reply to Nick Clifton from comment #13) > In the meantime you can, if you wish, use the objcopy program to completely > remove the note section, thus saving a lot of space. > > objcopy --remove-section=.gnu.buld.attributes libnm.so.0.1.0 Please do not recommend that, this kind of stripping really should not end up in RPM spec files. Can we somehow detect which packages need rebuilding? We won't need a full mass rebuild, just rebuilding affected packages should be enough.
(In reply to Florian Weimer from comment #14) Hi Florian, > Can we somehow detect which packages need rebuilding? We won't need a full > mass rebuild, just rebuilding affected packages should be enough. Checking for corrupt notes in a file should indicate that it needs rebuilding. eg: % readelf --wide --notes foo.exe | grep "Corrupt note" Testing an rpm could be done with the run-on-binaries-in script: % run-on-binaries-in foo.rpm readelf --wide --notes Is that the kind of answer you were looking for ? Cheers Nick
we should be able to work with that, yeah. mohan, can we script something up based on #c15 on a host with local disk access to a recent rawhide compose? that way we should be able to figure out what to rebuild. and same for f30/f31 I guess if the broken binutils made the buildroot...
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days