[OE-core] [PATCH] staging: Strip files in sysroot

[Andreas Müller]

On Tue, Jun 23, 2015 at 11:48 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Tue, 2015-06-23 at 20:19 +0200, Andreas Müller wrote:
>> On Tue, Jun 23, 2015 at 6:32 PM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>> >> Do I understand this right: Stripping is disabled by default (because
>> >> it would cause trouble for remote debugging)?
>> >
>> > No, this is only stripping of the sysroot files, not target. Its due to
>> > the way locale packaging happens for glibc. It does mean some files in
>> > the sysroot are not stripped when they could be but its no change from
>> > the existing behaviour before the patch.
>> >
>> > Cheers,
>> >
>> > Richard
>> >
>> Sorry for insisting - maybe I need more explanation:
>>
>> From my understanding staging sequence is:
>>
>> * do_install installs to recipe's image folder
>> * do_populate_sysroot -> sysroot_stage_all() creates hardlinks to
>> recipe's sysroot-destdir folder
>> * do_populate_sysroot -> sysroot_strip() strips files in recipe's
>> sysroot-destdir (=files in recipe's image folder)
>
> When it strips files, the hardlink is broken and replaced with a
> stripped copy.
>
>> * through sstate_install the files are hard linked to MACHINE's
>> sysroot (STAGING_DIR_HOST)
>>
>> I see two issues activating stripping
>>
>> 1. If do_package starts after stripping only stripped packages are
>> packed also for dbg. I think nothing gaurantees that packaging occurs
>> before do_populate_sysroot.
>
> Nothing does but the copy in image remains unstripped as above.
>
>> 2. When remote debugging I tell debugger: set sysroot <content of
>> STAGING_DIR_HOST>. Where do I find a unstripped sysroot now?
>
> That is not really the way the sysroot has been intended to be used.
> Inhibiting the sysroot stripping for target files would seem to be the
> best thing to do if you do wish to use the sysroot that way:
>
> INHIBIT_SYSROOT_STRIP_class-target = "1"
>
> Cheers,
>
Breaking hardlinks by stripping explains why there is no trouble to
expect. Thanks for explanation. I'll set INHIBIT_SYSROOT_STRIP = "1"
in my local.conf and am fine with spontaneous remote debugging.

Off topic: I have a class in meta-qt5-extra aligning paths in cmake
files. Because I am interested in keeping packed cmake files
unaligned, alignment is done only in local sysroot. To avoid trouble I
also break hardlinks (line 173).

This class is used for a while for all this kde/hawaii/lxqt stuff but
at least meta-qt5 has recipes where this class could be useful.

I saw there is an update for cmake pending. After consolidating from
this update: Would cmake-lib.bbclass have a chance in oe-core?

Andreas

[1] https://github.com/schnitzeltony/meta-qt5-extra/blob/master/classes/cmake-lib.bbclass