[yocto] sstate black hole?
Gary Thomas
gary at mlbassoc.com
Tue Apr 7 09:42:52 PDT 2015
On 2015-04-07 10:33, Martin Jansa wrote:
> On Tue, Apr 07, 2015 at 10:29:14AM -0600, Gary Thomas wrote:
>> On 2015-04-07 10:19, Martin Jansa wrote:
>>> On Tue, Apr 07, 2015 at 08:52:36AM -0600, Gary Thomas wrote:
>>>> I'm building for multiple ARM i.MX6 platforms. These have
>>>> the same SoC, but slightly different peripherals. As far as
>>>> I can tell, they should be able to share everything except
>>>> for a few ${MACHINE} specific packages, e.g. the kernel and
>>>> u-boot.
>>>>
>>>> Sadly, that doesn't seem to be the case. The architecture
>>>> specific packages are being split into two categories - plain
>>>> ARM/Cortex-A9 and those that have i.MX6 specific optimizations.
>>>> For example, after building a complete image (on the order of
>>>> core-image-sato), I have this split:
>>>> $ ls tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/
>>>> acl gst-player libsamplerate0 modutils-initscripts shadow-sysroot
>>>> alsa-utils gst-plugins-bad libsm mpeg2dec shared-mime-info
>>>> apmd gst-plugins-good libsndfile1 mplayer2 speex
>>>> atk gst-plugins-ugly libsoup-2.4 mtdev sqlite3
>>>> attr gstreamer libtheora ncurses startup-notification
>>>> base-passwd gstreamer1.0 libtirpc neon strace
>>>> ...
>>>> gst-ffmpeg libpostproc matchbox-wm scrnsaverproto zlib
>>>> gst-fluendo-mpegmux libproxy mkfontdir settings-daemon
>>>> gst-meta-base libpthread-stubs mkfontscale shadow
>>>>
>>>> $ ls tmp/work/cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi/
>>>> alsa-lib gst-plugins-base imx-gpu-viv libfslparser libsdl xf86-video-imxfb-vivante
>>>> cairo gstreamer1.0-plugins-bad libdrm libfslvpuwrap mesa xserver-xorg
>>>> firmware-imx gstreamer1.0-plugins-base libfslcodec libglu pulseaudio
>>>>
>>>> It's the second category that is causing problems. They do not
>>>> seem to end up in any shareable sstate at all. If I try to rebuild
>>>> using only sstate, i.e. build my complete image to success, then
>>>> remove 'tmp' and rebuild, using the sstate-cache from the first go,
>>>> all of the above packages (alsa-lib, ..., xserver-xorg) are all
>>>> rebuilt from scratch. Those recipes do seem to end in my sstate-cache,
>>>> but they are never reused from it.
>>>>
>>>> What would make this happen? How can I prevent it?
>>>>
>>>> As is, sstate is not really shareable between these i.MX6 targets
>>>> as so much is being rebuilt all the time...
>>>>
>>>> Any ideas or pointers gladly welcomed.
>>>
>>> Try openembedded-core/scripts/sstate-diff-machines.sh
>>> to see why.
>>>
>>
>> Can this work if I build for the two machines in separate trees?
>
> Yes, you can generate the report in each tree separately and then
> compare them in one of them.
>
>> Also, I'm really trying to find out why a build for the same machine
>> doesn't reuse sstate, in the same build tree, back-to-back builds
>> (no metadata changes)
>
> Sorry, is "the same build tree" something else than "the two machines in
> separate trees" or are you testing both?
>
Both actually, but at the moment the most interesting problem
is for a given machine that sstate is not being [re]used for
these recipes.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
More information about the yocto
mailing list