<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K <span dir="ltr"><<a href="mailto:stephen.k.jolley@intel.com" target="_blank">stephen.k.jolley@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span style="font-size:10.0pt;font-family:Symbol;color:black"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">There is a multilib issue related to the layout of the host libraries leaking into python’s build process which we’re struggling to debug</span></blockquote></div><br>Could I get some details on this? I've seen something like this where cmake and automake are relying on sys.lib from python3-native/python-native to determine the sitepackages directory, is that the behavior others are hitting? So python modules end up in /usr/lib/ rather than /usr/lib64/, for example?</div><div class="gmail_extra"><br></div><div class="gmail_extra">If that's the issue in question, the issue is the mismatch between the native sys.lib and target. We already patch automake to fall back to using our libdir + python version to determine the path, but only if it wasn't able to use sys.lib to do so. If we change that to always use libdir+python version, it should fix the automake packages. Then we might need to patch FindPythonLibs in cmake to do the same. I'm testing the automake change locally now.<br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>