Comments

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@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(-)

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@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