| Message ID | 20170912155906.29716-1-ross.burton@intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | allarch: don't reset baselib | expand |
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")) > } > - > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 <div dir="ltr">On 12 September 2017 at 17:28, Mark Hatle <span dir="ltr"><<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/12/17 10:59 AM, Ross Burton wrote:<br> > allarch currently resets baselib to "lib" in an attempt to keep allarch recipes<br> > uniform. However if the real value for $baselib is actually needed, for example<br> > in a multilib environment where $baselib is lib64 for standard binaries and the<br> > allarch package is using postinst intercepts which need to know the real value<br> > of $libdir, then a non-existant or incorrect $libdir will be used.<br> ><br> > Real world example: liberation-fonts is allarch and inherits fontcache, which<br> > uses a postinst intercept to run fc-cache inside qemu-user. In a multilib<br> > configuration where normal libdir=/usr/lib64 and lib32 libdir=/usr/lib qemu will<br> > try running a 64-bit fc-cache with a 32-bit ld-linux, and predicatably the<br> > binary crashes.<br> <br> </span>This still won't work right. If we put an allarch package in a configuration<br> that can be either 32-bit or 64-bit (which is the point of allarch), then how<br> will it know which arch this magic script is running on?<br> <br> It sounds to me like the way the script is running needs to be fixed (and/or<br> qemu needs to be fixed). Calls to QEMU should inherit the matching system<br> envrionment, not assume an environment from the post-install scripts.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>Also its interesting that nobody else noticed this: multilib images that installed fonts were segfaulting in rootfs...</div><div><br></div><div>Ross</div></div></div></div> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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")) } -
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(-) -- 2.11.0 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core