Re: [yocto] [OE-core] Yocto Project Status WW25

2016-06-17 Thread Richard Purdie
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


Re: [yocto] [OE-core] Yocto Project Status WW25

2016-06-17 Thread Christopher Larson
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

2016-06-17 Thread Christopher Larson
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