Bugzilla – Bug 1095101
cross-avr-gcc7 contains debug info and thus is huge
Last modified: 2018-05-30 09:17:16 UTC
strolchi:~ # rpm -qi cross-avr-gcc7 Name : cross-avr-gcc7 Version : 7.3.1+r258812 Release : 3.5 Architecture: x86_64 Install Date: Tue May 29 22:08:41 2018 Group : Development/Languages/C and C++ Size : 1012705032 License : GPL-3.0+ Signature : RSA/SHA256, Wed May 23 21:09:13 2018, Key ID b88b2fd43dbdc284 Source RPM : cross-avr-gcc7-7.3.1+r258812-3.5.src.rpm Build Date : Wed May 23 21:07:04 2018 [...] Distribution: openSUSE Tumbleweed The package is 965.8MiB big. A bit excessive IMHO. strolchi:~ # file /usr/lib64/gcc/avr/7/cc1plus /usr/lib64/gcc/avr/7/cc1plus: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=cb0abefc99f7b9f68f41b0c994a9b86eaf3f3493, with debug_info, not stripped We should probably strip this out into a -debuginfo package.
This depends on fixing the debuginfo stripping parts in rpm. Not sure if there's an existing bug for that but I wouldn't be surprised (it must then be >5 years old...). In the gcc spec files we do the following to avoid running into debugedit crashes and thus package build fails: # install and fixup target parts # debugedit is not prepared for this and crashes %if 0%{?gcc_icecream:1} # so expect the sysroot to be populated from natively built binaries %else %if 0%{!?gcc_libc_bootstrap:1} export NO_BRP_STRIP_DEBUG=true export NO_DEBUGINFO_STRIP_DEBUG=true %define __debug_install_post %{nil} : >../debugfiles.list : >../debugsourcefiles.list : >../debugsources.list unfortunately this not only affects the problematic target parts but also the host parts (cc1 and friends) which is why the packages end up being so huge. So a better workaround but still similar to the above would be to try fix this in find-debuginfo.sh (from rpm) and simply skip all non-native binaries, leaving their debuginfo in place (unfortunately the stripping part is also done separately in brp-strip IIRC). So yes, this bug is real but it's a bug in rpm and can only be fixed there. Michael, can you have a look please? You can use cross-avr-gcc7.spec from the gcc7 source package for testing after commenting out the above quoted parts.
So looks like cross-avr-gcc is a bad example since it builds fine. There's gazillions of [ 565s] strip: Unable to recognise the format of the input file `/home/abuild/rpmbuild/BUILDROOT/cross-avr-gcc7-7.3.1+r258812-0.x86_64/usr/lib64/gcc/avr/7/tiny-stack/libgcc.a(_satfractUQQSA.o)' which is from brp-strip and [ 614s] cross-avr-gcc7.x86_64: W: static-library-without-debuginfo /usr/lib64/gcc/avr/7/avrxmega5/libgcov.a which is probably a false positive (same reason, some tool not handling non-native binary formats?) That said, brp-strip should just go away and move to find-debuginfo.sh. Since cross-avr-gcc doesn't contain any shared avr objects debuginfo stripping does nothing here. It might be the workaround was for older distros. Andreas, do you remember?
(In reply to Richard Biener from comment #2) > Andreas, do you remember? It was not about a build failure but rather about the packaged target binaries (e.g., crt*.o) getting damaged and thus the resulting toolchain not able to compile code at runtime. Compiling an empty int main(void) { return 0; } should expose this.