[OE-core] [PATCH] allarch: don't reset baselib

[Burton, Ross]

On 12 September 2017 at 17:28, Mark Hatle <mark.hatle at windriver.com> wrote:

> On 9/12/17 10:59 AM, Ross Burton wrote:
> > allarch currently resets baselib to "lib" in an attempt to keep allarch
> recipes
> > uniform.  However if the real value for $baselib is actually needed, for
> example
> > in a multilib environment where $baselib is lib64 for standard binaries
> and the
> > allarch package is using postinst intercepts which need to know the real
> value
> > of $libdir, then a non-existant or incorrect $libdir will be used.
> >
> > Real world example: liberation-fonts is allarch and inherits fontcache,
> which
> > uses a postinst intercept to run fc-cache inside qemu-user.  In a
> multilib
> > configuration where normal libdir=/usr/lib64 and lib32 libdir=/usr/lib
> qemu will
> > try running a 64-bit fc-cache with a 32-bit ld-linux, and predicatably
> the
> > binary crashes.
>
> This still won't work right.  If we put an allarch package in a
> configuration
> that can be either 32-bit or 64-bit (which is the point of allarch), then
> how
> will it know which arch this magic script is running on?
>
> It sounds to me like the way the script is running needs to be fixed
> (and/or
> qemu needs to be fixed).   Calls to QEMU should inherit the matching system
> envrionment, not assume an environment from the post-install scripts.
>

There's several problems, yes.  qemu needs to handle this more gracefully,
but it's clearly being told by the postinst-intercept framework to run a
binary in rootfs/usr/bin (64-bit) using libraries in rootfs/usr/lib
(32-bit).  By not resetting baselib at least allarch packages think libdir
is the "native" libdir, not whatever /usr/lib happens to be.

I guess the true solution is for the recipes to not need to know the
library path.  Not sure how to do that yet though...

Also its interesting that nobody else noticed this: multilib images that
installed fonts were segfaulting in rootfs...

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170912/c0bad375/attachment-0002.html>