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