[PATCH] allarch: don't reset baselib

[PATCH] allarch: don't reset baselib

[Ross Burton]

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.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/classes/allarch.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 51ba509cd0a..e0326039d0c 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -13,7 +13,7 @@ python () {
 
         # Set these to a common set of values, we shouldn't be using them other that for WORKDIR directory
         # naming anyway
-        d.setVar("baselib", "lib")
+        #d.setVar("baselib", "lib")
         d.setVar("TARGET_ARCH", "allarch")
         d.setVar("TARGET_OS", "linux")
         d.setVar("TARGET_CC_ARCH", "none")
@@ -48,4 +48,3 @@ python () {
     elif bb.data.inherits_class('packagegroup', d) and not bb.data.inherits_class('nativesdk', d):
         bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit packagegroup" % d.getVar("FILE"))
 }
-
-- 
2.11.0

Re: [PATCH] allarch: don't reset baselib

[Mark Hatle]

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.

--Mark

> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/classes/allarch.bbclass | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> index 51ba509cd0a..e0326039d0c 100644
> --- a/meta/classes/allarch.bbclass
> +++ b/meta/classes/allarch.bbclass
> @@ -13,7 +13,7 @@ python () {
>  
>          # Set these to a common set of values, we shouldn't be using them other that for WORKDIR directory
>          # naming anyway
> -        d.setVar("baselib", "lib")
> +        #d.setVar("baselib", "lib")
>          d.setVar("TARGET_ARCH", "allarch")
>          d.setVar("TARGET_OS", "linux")
>          d.setVar("TARGET_CC_ARCH", "none")
> @@ -48,4 +48,3 @@ python () {
>      elif bb.data.inherits_class('packagegroup', d) and not bb.data.inherits_class('nativesdk', d):
>          bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit packagegroup" % d.getVar("FILE"))
>  }
> -
> 

Re: [PATCH] allarch: don't reset baselib

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

On 12 September 2017 at 17:28, Mark Hatle <mark.hatle@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

[-- Attachment #2: Type: text/html, Size: 2473 bytes --]

Re: [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@windriver.com
> <mailto:mark.hatle@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

Re: [PATCH] allarch: don't reset baselib

[Alexander Kanavin]

On 09/12/2017 08:31 PM, Mark Hatle wrote:

>> 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 still believe sweeping genuine postinst errors under the carpet like 
this is wrong, and I maintain a patchset to address it:

https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/dnf-rpm4-postinst-fix

Will re-submit after 2.4 is out.


Alex