[OE-core] [PATCH] postinst-intercepts, qemu.bbclass: fix segfaults in postinstalls

[Richard Purdie]

On Wed, 2013-04-10 at 10:38 +0300, Laurentiu Palcu wrote:
> 
> On 04/10/2013 12:58 AM, Richard Purdie wrote:
> > On Tue, 2013-04-09 at 18:53 +0300, Laurentiu Palcu wrote:
> >> Postinstalls that use qemu are throwing a segmentation fault when
> >> building for qemux86-64 on a 64bit host (it might also happen for
> >> qemux86 if building on a 32bit host but I didn't test). It looks like
> >> qemu looks for ld.so.cache which is not found because it is generated
> >> after rootfs_(rpm|ipk|deb)_do_rootfs is called and then it tries to load
> >> libraries from the default paths (which are the host's). In order to
> >> avoid this, pass the LD_LIBRARY_PATH explicitly to the target's dynamic
> >> loader.
> >>
> >> Signed-off-by: Laurentiu Palcu <laurentiu.palcu at intel.com>
> >> ---
> >>  meta/classes/qemu.bbclass                       |    4 +++-
> >>  scripts/postinst-intercepts/update_font_cache   |    3 ++-
> >>  scripts/postinst-intercepts/update_pixbuf_cache |    3 ++-
> >>  3 files changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
> >> index 0e71d6a..6881826 100644
> >> --- a/meta/classes/qemu.bbclass
> >> +++ b/meta/classes/qemu.bbclass
> >> @@ -29,4 +29,6 @@ def qemu_run_binary(data, rootfs_path, binary):
> >>      if qemu_binary == "qemu-allarch":
> >>          qemu_binary = "qemuwrapper"
> >>  
> >> -    return "PSEUDO_UNLOAD=1 " + qemu_binary + " -L " + rootfs_path + " " + rootfs_path + binary
> >> +    return "PSEUDO_UNLOAD=1 " + qemu_binary + " -L " + rootfs_path\
> >> +            + " -E LD_LIBRARY_PATH=" + rootfs_path + "/lib:" + rootfs_path\
> >> +            + "/usr/lib " + rootfs_path + binary
> > 
> > This isn't going to work with multilibs. Can we reorder the rootfs code
> > so the ld.so.cache piece happens before the intercepts?
> I keep forgetting about multilib... :( I'll find another way.
> Unfortunately, it's not enough to generate ld.so.cache before running
> the intercept hooks because there are other package postinstalls that
> need qemu and those will be run before that. What if, instead of
> hardcoding, we use ${libdir} and ${base_libdir}?. These should always
> point to the right locations even when working with multilib.

With any given binary, you're not going to know which libdir is the
right one though?

Looking at a multilib image, the cache is bust on multilib anyway. In
reality this just makes things slower, it will still work. The source to
ldconfig-native hardcodes LIBDIR/SLIBDIR.

What is the path being used for? Just to find ld.so? Once we get ld.so,
does it provide the right paths from then onwards? If I understand the
changes here, we appear to by bypassing ld.so?

Cheers,

Richard