[prev in list] [next in list] [prev in thread] [next in thread]
List: openembedded-core
Subject: Re: [OE-core] [PATCH] python3: correct the multilib support patch
From: Dan McGregor <danismostlikely () gmail ! com>
Date: 2016-06-29 22:47:05
Message-ID: CACS+7ZTjDFw--YRTNae6pEbPaqTbysD021zY2LDD9sqqCOvf8A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 29 Jun 2016 9:44 a.m., "Randle, William C" <william.c.randle@intel.com>
wrote:
>
> On Wed, 2016-06-29 at 07:33 +0100, Richard Purdie wrote:
>>
>> On Wed, 2016-06-29 at 11:12 +0800, Li Zhou wrote:
>>>
>>> When python3 rebased its multilib patch, the hard coded "lib" path
>>> isn't really changed because of the rebasing's error, and cause
>>> phthon3's failure when running on 64bit platforms as below:
>>> Could not find platform independent libraries <prefix>
>>> Could not find platform dependent libraries <exec_prefix>
>>> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
>>> Fatal Python error: Py_Initialize: Unable to get the locale encoding
>>> ImportError: No module named 'encodings'
>>>
>>> Here correct the rebasing error and solve this issue.
>>>
>>> Signed-off-by: Li Zhou <li.zhou@windriver.com>
>>> ---
>>> ...ython3-correct-the-multilib-support-patch.patch | 47
>>> ++++++++++++++++++++++
>>> meta/recipes-devtools/python/python3_3.5.1.bb | 1 +
>>> 2 files changed, 48 insertions(+)
>>> create mode 100644 meta/recipes-devtools/python/python3/0001-python3
>>> -correct-the-multilib-support-patch.patch
>>
>>
>>
>> Don't we want to correct the "bad" patch rather than adding an
>> additional patch? Or did I misunderstand the problem?
>>
>> Also, are there some automated tests we should be adding to catch this
>> kind of problem? I'm a little worried none of our testing caught this.
>>
>> Cheers,
>>
>> Richard
>
>
> I would agree that since the original patch has not been accepted
upstream, it would make the most sense to just regenerate it.
>
> In addition, there are a couple of other places in getpath.c that have a
hard coded "lib/". Have you verified those are correct as is? (I.e., ~line
706 'L:lib/pyhton00.zip"' and ~line 718 'L"lib/lib-dynload"'. Seems like
the second case should use code similar other palces lib-dynload is used in
the file that uses lib_python to build the path.)
>
> -Bill
Fedora and others have similar patches. Have people checked them out?
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[Attachment #5 (text/html)]
<p dir="ltr">On 29 Jun 2016 9:44 a.m., "Randle, William C" <<a \
href="mailto:william.c.randle@intel.com">william.c.randle@intel.com</a>> \
wrote:<br> ><br>
> On Wed, 2016-06-29 at 07:33 +0100, Richard Purdie wrote:<br>
>><br>
>> On Wed, 2016-06-29 at 11:12 +0800, Li Zhou wrote:<br>
>>><br>
>>> When python3 rebased its multilib patch, the hard coded "lib" \
path<br> >>> isn't really changed because of the rebasing's error, \
and cause<br> >>> phthon3's failure when running on 64bit platforms as \
below:<br> >>> Could not find platform independent libraries \
<prefix><br> >>> Could not find platform dependent libraries \
<exec_prefix><br> >>> Consider setting $PYTHONHOME to \
<prefix>[:<exec_prefix>]<br> >>> Fatal Python error: \
Py_Initialize: Unable to get the locale encoding<br> >>> ImportError: No \
module named 'encodings'<br> >>><br>
>>> Here correct the rebasing error and solve this issue.<br>
>>><br>
>>> Signed-off-by: Li Zhou <<a \
href="mailto:li.zhou@windriver.com">li.zhou@windriver.com</a>><br> >>> \
---<br> >>> ...ython3-correct-the-multilib-support-patch.patch | 47<br>
>>> ++++++++++++++++++++++<br>
>>> meta/recipes-devtools/python/<a \
href="http://python3_3.5.1.bb">python3_3.5.1.bb</a> | 1 +<br> \
>>> 2 files changed, 48 insertions(+)<br> >>> create mode \
100644 meta/recipes-devtools/python/python3/0001-python3<br> >>> \
-correct-the-multilib-support-patch.patch<br> >><br>
>><br>
>><br>
>> Don't we want to correct the "bad" patch rather than adding \
an<br> >> additional patch? Or did I misunderstand the problem?<br>
>><br>
>> Also, are there some automated tests we should be adding to catch this<br>
>> kind of problem? I'm a little worried none of our testing caught \
this.<br> >><br>
>> Cheers,<br>
>><br>
>> Richard<br>
><br>
><br>
> I would agree that since the original patch has not been accepted upstream, it \
would make the most sense to just regenerate it.<br> ><br>
> In addition, there are a couple of other places in getpath.c that have a hard \
coded "lib/". Have you verified those are correct as is? (I.e., ~line 706 \
'L:lib/pyhton00.zip"' and ~line 718 \
'L"lib/lib-dynload"'. Seems like the second case should use code \
similar other palces lib-dynload is used in the file that uses lib_python to build \
the path.)<br> ><br>
> -Bill</p>
<p dir="ltr">Fedora and others have similar patches. Have people checked them \
out?</p> <p dir="ltr">><br>
> --<br>
> _______________________________________________<br>
> Openembedded-core mailing list<br>
> <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
><br>
</p>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic