Bug 1095101 - cross-avr-gcc7 contains debug info and thus is huge
cross-avr-gcc7 contains debug info and thus is huge
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Michael Schröder
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-05-29 20:15 UTC by Stefan Seyfried
Modified: 2018-05-30 09:17 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
rguenther: needinfo? (mls)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Seyfried 2018-05-29 20:15:54 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.
Comment 1 Richard Biener 2018-05-30 07:12:40 UTC
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.
Comment 2 Richard Biener 2018-05-30 09:02:23 UTC
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?
Comment 3 Andreas Färber 2018-05-30 09:17:16 UTC
(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.