Comment # 16 on bug 1152590 from Richard Biener

(In reply to Andreas F�rber from comment #15)
> (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