[Bug 1152590] New: cross-avr-gcc* are huge
http://bugzilla.suse.com/show_bug.cgi?id=1152590 Bug ID: 1152590 Summary: cross-avr-gcc* are huge Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: rguenther@suse.com Reporter: jslaby@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I want to cross-compile for avrs, so I installed cross-avr-gcc9, but the rpm is HUGE. Look: https://download.opensuse.org/repositories/devel:/gcc/openSUSE_Factory/x86_6... cross-avr and cross-rx binaries seem to be unstripped -- no debuginfo package, the debuginfo is inline. Picking some of the files from the rpm: 187818848 Sep 23 16:21 /usr/lib64/gcc/avr/9/cc1 199320384 Sep 23 16:21 /usr/lib64/gcc/avr/9/cc1plus 179107056 Sep 23 16:21 /usr/lib64/gcc/avr/9/lto1 Almost 200M each... # objdump -h /usr/lib64/gcc/avr/9/lto1 |grep \\.debug 31 .debug_aranges 0000db70 0000000000000000 0000000000000000 00d21db0 2**4 32 .debug_info 04ad324b 0000000000000000 0000000000000000 00d2f920 2**0 33 .debug_abbrev 001aa282 0000000000000000 0000000000000000 05802b6b 2**0 34 .debug_line 00c54dd7 0000000000000000 0000000000000000 059acded 2**0 35 .debug_str 0053d6db 0000000000000000 0000000000000000 06601bc4 2**0 36 .debug_loc 02f2cce9 0000000000000000 0000000000000000 06b3f29f 2**0 37 .debug_ranges 00e77270 0000000000000000 0000000000000000 09a6bf90 2**4 On the other hand, from cross-arm-gcc9: 18859160 Aug 23 14:00 /usr/lib64/gcc/arm-suse-linux-gnueabi/9/cc1 20189880 Aug 23 14:00 /usr/lib64/gcc/arm-suse-linux-gnueabi/9/cc1plus 17903416 Aug 23 14:00 /usr/lib64/gcc/arm-suse-linux-gnueabi/9/lto1 By the order of magnitude smaller: around 20M. # objdump -h /usr/lib64/gcc/arm-suse-linux-gnueabi/9/lto1 |grep \\.debug <Nothing> So stripping lto1 manually: # cp /usr/lib64/gcc/avr/9/lto1 . # strip /usr/lib64/gcc/avr/9/lto1 # ll -h lto1 /usr/lib64/gcc/avr/9/lto1 -rwxr-xr-x 1 root root 171M 1. říj 09.07 lto1 -rwxr-xr-x 1 root root 14M 1. říj 09.07 /usr/lib64/gcc/avr/9/lto1 So what went wrong during the build? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c1
--- Comment #1 from Jiri Slaby
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c2
Richard Biener
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c3
--- Comment #3 from Jiri Slaby
[ 817s] objcopy: Unable to recognise the format of the input file `/home/abuild/rpmbuild/BUILDROOT/cross-avr-gcc9-9.2.1+r275327-1.1.x86_64/usr/ lib64/gcc/avr/9/tiny-stack/libgcc.a(_satfractHQUTA.o)' ...
OK, I understand avr objects cannot be handled w/o binutils support, but why are not native binaries (like cc1 or lto1) handled (the same as in cross-avr-binutils)?
Micha? Andreas? Adding avr to this list is easy (we should at least have all enabled that we build cross-binutils packages for I guess, epiphany is also missing).
And rx as I noted above. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c4
--- Comment #4 from Richard Biener
(In reply to Richard Biener from comment #2)
[ 817s] objcopy: Unable to recognise the format of the input file `/home/abuild/rpmbuild/BUILDROOT/cross-avr-gcc9-9.2.1+r275327-1.1.x86_64/usr/ lib64/gcc/avr/9/tiny-stack/libgcc.a(_satfractHQUTA.o)' ...
OK, I understand avr objects cannot be handled w/o binutils support, but why are not native binaries (like cc1 or lto1) handled (the same as in cross-avr-binutils)?
I would guess the debuginfo extraction machinery simply gives up completely after errors. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c5
--- Comment #5 from Michael Matz
[ 817s] objcopy: Unable to recognise the format of the input file `/home/abuild/rpmbuild/BUILDROOT/cross-avr-gcc9-9.2.1+r275327-1.1.x86_64/usr/ lib64/gcc/avr/9/tiny-stack/libgcc.a(_satfractHQUTA.o)' ...
OK, I understand avr objects cannot be handled w/o binutils support, but why are not native binaries (like cc1 or lto1) handled (the same as in cross-avr-binutils)?
I would guess the debuginfo extraction machinery simply gives up completely after errors.
I guess that would be a good enhancement to only selectively ignore inputs that can't be handled, instead of completely giving up on generating debug info packages. (This would mean the target objects and libraries would contain debug info for some architectures, which might not be the worst thing). In any case, I'm enabling targets for binutils only selectively so that the CVE-generating script kiddies have less chance to annoy me. But I agree that the generic binutils should be able to handle the architectures we otherwise support as cross targets. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c6
--- Comment #6 from Jiri Slaby
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c7
Jiri Slaby
This mangling does not happen with binutils with avr support in the above project. Let me check whether linking works once this all gets build.
yes, after making examples/demo from avr-libc, the result now looks sensible: objdump -b binary -m avr:4 -D demo.bin demo.bin: file format binary Disassembly of section .data: 00000000 <.data>: 0: 12 c0 rjmp .+36 ; 0x26 2: 21 c0 rjmp .+66 ; 0x46 4: 20 c0 rjmp .+64 ; 0x46 6: 1f c0 rjmp .+62 ; 0x46 ... ea: f8 94 cli ec: ff cf rjmp .-2 ; 0xec I have noticed the update just landed to devel:gcc/binutils. We are done here, I think. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c8
Jiri Slaby
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c9
--- Comment #9 from Michael Matz
I have noticed the update just landed to devel:gcc/binutils. We are done here, I think.
Yeah, but as I used a slightly different approach than you please test those binutils as well. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c10
--- Comment #10 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c11
--- Comment #11 from Jiri Slaby
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c12
Jiri Slaby
export NO_BRP_STRIP_DEBUG=true export NO_DEBUGINFO_STRIP_DEBUG=true %define __debug_install_post %{nil}
Commenting these 3 lines frees 500M on disk and the linked binary (using such built toolchain) has the same md5 hash. They were added in rev 40 of gcc5: osc rdiff -c 40 devel:gcc gcc5 +Tue Apr 7 09:55:38 UTC 2015 - afaerber@suse.de + +- Prepare for non-icecream cross-compilers +* Define sysroot to match cross-binutils config +* Prepare for requiring cross-newlib for some targets +* Use all-host target for libc bootstrap, too +* Install target files, but suppress stripping them (breaks them) +* Suppress -icecream-backend subpackage +* Allow building on any architecture (In reply to Michael Matz from comment #9)
Yeah, but as I used a slightly different approach than you please test those binutils as well.
It still works. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c13
Richard Biener
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c14
--- Comment #14 from Richard Biener
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c15
--- Comment #15 from Andreas Färber
(In reply to Jiri Slaby from comment #11)
export NO_BRP_STRIP_DEBUG=true export NO_DEBUGINFO_STRIP_DEBUG=true %define __debug_install_post %{nil}
Commenting these 3 lines frees 500M on disk and the linked binary (using such built toolchain) has the same md5 hash.
They were added in rev 40 of gcc5: osc rdiff -c 40 devel:gcc gcc5
+Tue Apr 7 09:55:38 UTC 2015 - afaerber@suse.de + +- Prepare for non-icecream cross-compilers +* Define sysroot to match cross-binutils config +* Prepare for requiring cross-newlib for some targets +* Use all-host target for libc bootstrap, too +* Install target files, but suppress stripping them (breaks them)
There you have the reason: OBS destroyed .o, .a or whatever files for the non-native architecture. This was the only workaround we had. Richie, before you revert any such workaround, please assure that it can actually link without it. Last Hackweek I had prepared a simple "testsuite" for linking target binaries here: https://build.opensuse.org/project/show/home:a_faerber:branches:devel:gcc:cr... Of course the links broke due to gcc updates since, and it uncovered the epiphany cross-compiler having regressed, so to get it accepted I assume we'd at least need to suppress the package from showing as Failed...
+* Suppress -icecream-backend subpackage +* Allow building on any architecture
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c16
--- Comment #16 from Richard Biener
(In reply to Jiri Slaby from comment #12)
(In reply to Jiri Slaby from comment #11)
export NO_BRP_STRIP_DEBUG=true export NO_DEBUGINFO_STRIP_DEBUG=true %define __debug_install_post %{nil}
Commenting these 3 lines frees 500M on disk and the linked binary (using such built toolchain) has the same md5 hash.
They were added in rev 40 of gcc5: osc rdiff -c 40 devel:gcc gcc5
+Tue Apr 7 09:55:38 UTC 2015 - afaerber@suse.de + +- Prepare for non-icecream cross-compilers +* Define sysroot to match cross-binutils config +* Prepare for requiring cross-newlib for some targets +* Use all-host target for libc bootstrap, too +* Install target files, but suppress stripping them (breaks them)
There you have the reason: OBS destroyed .o, .a or whatever files for the non-native architecture. This was the only workaround we had.
Yes. But did anybody actually file a bug for brp-strip or whatever was doing this?
Richie, before you revert any such workaround, please assure that it can actually link without it. Last Hackweek I had prepared a simple "testsuite" for linking target binaries here: https://build.opensuse.org/project/show/home:a_faerber:branches:devel:gcc: cross-test
Of course the links broke due to gcc updates since, and it uncovered the epiphany cross-compiler having regressed, so to get it accepted I assume we'd at least need to suppress the package from showing as Failed...
Yes, I remember asking for that. Note the appropriate "workaround" is to make strip/objcopy recognize the architecture for the targets we build cross compilers for. I actually cannot reproduce the issue for any cross target right now, I wanted to do sth like ... create target object file ... strip test.o ... check if it is valid ... else .. do current workaround .. at the end of %build or %install but as said, I couldn't actually test it. I guess we really only can get at the "installed" toolchain from a separate package / spec file. I've meanwhile "fixed" devel:gcc/gcc9
+* Suppress -icecream-backend subpackage +* Allow building on any architecture
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c17
--- Comment #17 from Andreas Färber
http://bugzilla.suse.com/show_bug.cgi?id=1152590
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c21
--- Comment #21 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c22
--- Comment #22 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c23
--- Comment #23 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c24
--- Comment #24 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c25
--- Comment #25 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c26
--- Comment #26 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c29
--- Comment #29 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1152590
http://bugzilla.suse.com/show_bug.cgi?id=1152590#c30
--- Comment #30 from Swamp Workflow Management
https://bugzilla.suse.com/show_bug.cgi?id=1152590
https://bugzilla.suse.com/show_bug.cgi?id=1152590#c31
--- Comment #31 from Swamp Workflow Management
https://bugzilla.suse.com/show_bug.cgi?id=1152590
https://bugzilla.suse.com/show_bug.cgi?id=1152590#c32
--- Comment #32 from Swamp Workflow Management
https://bugzilla.suse.com/show_bug.cgi?id=1152590
https://bugzilla.suse.com/show_bug.cgi?id=1152590#c33
Richard Biener
participants (2)
-
bugzilla_noreply@novell.com
-
bugzilla_noreply@suse.com