stripping changes

[lrusak]

picked and fixed up some commits from @stefansaraev

This changes the way that stripping works. @sraue please look over.

@stefansaraev if you want me to remove you as author of the commits let me know (because I had to fixup and reword some of the commits)

Are these all the packages that need stripping or are there others?

[stefansaraev]

Are these all the packages that need stripping or are there others?

they are in my fork. but I removed like 75% of openelec packages there.

you can find out with

find /bin /sbin /usr /lib -perm /o+x | xargs file | grep "not stripped"

also. binary addons will be unstripped now, too. in my git - I want em like that.

[sraue]

whats the benefit from this all?, esp. not using "-s" for the linker?

[MilhouseVH]

If this can improve the crashlog stack traces we get from libc on ARM when not building with debug then I'm all for it. It has increased the size of SYSTEM by 3.7MB (on RPi2) but that's to be expected. Maybe you could strip for release (as this has no crashlog support), partial strip for devel and not strip at all for debug?

[stefansaraev]

3.7MB is nothing, compared to (mostly unneeded) dvb/wlan firmware/drivers included, and nvidia drivers (now 2 drivers in generic..)

I'd say keep it as-is ("partialy" stripped) on release builds, I converted gdb to an addon in my git, that's usable on release builds too, any backtrace is better than corrupted backtrace, or no backtrace at all.

[lrusak]

is that 3.7MB directly from not stripping glibc? I assume not. I'm just building now to see if there is anything else that can/should be stripped.

[MilhouseVH]

Just the size diff between two builds. 3.7MB isn't a big deal if it's useful and better stacktraces would be useful.

[MilhouseVH]

I've noticed that tvheadend and vdr-addon zips have increased in size somewhat (2.3MB and 180KB) since including this change... I guess we're not stripping these addons, is there anything to be gained by not stripping unofficial addons?

[lrusak]

Hmm, the add-ons should be stripped. Not sure why they aren't.

[sraue]

not sure about this PR.... dont like it much actually unless i can see some benefits from this...

[stefansaraev]

you really dont see benefits of proper debugging? you must not be damn serious ;)

[MilhouseVH]

not sure about this PR.... dont like it much actually unless i can see some benefits from this...

Without this PR: http://sprunge.us/TRgH
With this PR: http://sprunge.us/GgRN

That's just running kill -SEGV $(pidof kodi.bin) to force a crash, but the difference (and potential benefit) should be obvious.

[lrusak]

@sraue good to go?

[sraue]

not really...

[lrusak]

The decision is either:

1. increase the size of builds by a couple MB and have proper stack traces for core dumps
2. keep having corrupt stack traces

I think options number 1 is the better choice here.

[MilhouseVH]

Hmm, the add-ons should be stripped. Not sure why they aren't.

This is my only "concern" with this PR, otherwise I think it's proven it's worth several times already (in my test builds at least, with non-debug-enabled crashlogs now being useful when before this PR they were basically rubbish and only useful if you were really really lucky).