Re: [yocto] [OE-core] Yocto Project Status WW25
On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K < stephen.k.jol...@intel.com> wrote: > ·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 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? 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. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW25
On Fri, Jun 17, 2016 at 2:42 PM, Christopher Larson wrote: > On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K < > stephen.k.jol...@intel.com> wrote: > >> ·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 > > > 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? > > 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. > Hmm, nevermind, seems that was fixed in oe-core already, huzzah :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW25
On Fri, 2016-06-17 at 14:42 -0700, Christopher Larson wrote: > On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K < > stephen.k.jol...@intel.com> wrote: > > ·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 > 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? > > 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. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9717 is the bug Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto