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

[Mark Hatle]

On 9/12/17 11:34 AM, Burton, Ross wrote:
> On 12 September 2017 at 17:28, Mark Hatle <mark.hatle at windriver.com
> <mailto: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.

The call to qemu really should not be embedded into the postinst-intercept
script.  The framework itself is what should 'know' what it is doing and deal
with it.  The package can provide hints.. perhaps something like:

call-qemu <arch> <command>

Then the postinst stuff would implement the call-qemu 'function' (wrapper or
whatever) that would do the right thing for a given arch specified.

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

If the segfault is causing the postinst to exit w/ an error (non-0) then it's
likely re-running on the target itself (and thus working).  If not, ugh.

I don't have a good answer how to resolve this 'right now' with the time we have.

--Mark