On 9/12/17 11:34 AM, Burton, Ross wrote: > On 12 September 2017 at 17:28, Mark Hatle <[email protected] > <mailto:[email protected]>> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
