From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by mail.openembedded.org (Postfix) with ESMTP id DF68D60043 for ; Wed, 29 Jun 2016 22:47:05 +0000 (UTC) Received: by mail-vk0-f52.google.com with SMTP id j3so86261995vkb.0 for ; Wed, 29 Jun 2016 15:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=j0h/qQwnxnrbhI6OYtl+zZQlmWl2CnS3/jj4aOMNr3c=; b=vvDp4hoZaNRYgIdHnH2VpsmrisF73+cbr3izOvUofBSTTLKQHJZPzRGY5+uZbg2lsr PtHbPI6ordXD7KQQl7AYqh9ISVWloqYXtZ31ia4HuLqGoVztAPKkl0zDWzGF6MKoA8u7 YODvJmvr9sbyVoVIhdKlezqxDdS+zV7ARD4qB5xrr5/8G0vTBYjRU5EaHG+gULfB1hz9 rMGMO3zEaLeaxC+Xo3bu/NljUyeLP4DVdq1lvCDJtXM872xXx6YwYxrMUIIpDM6RBaqx H45Iw4TSn+cR3ogooT6/S9IlDEMz0mEqSO8y9ZRq93sXBfHxqozbw04/nEWikyFxFM88 PvQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=j0h/qQwnxnrbhI6OYtl+zZQlmWl2CnS3/jj4aOMNr3c=; b=M4mWfhKv0EVJAKJHpp9+lGcrFog9Os2KBjB3g8CyVIEaMaVBpwO0F33v5ntq3WDS6F jG6Cqb8JDvZGlF5pCl6FkNrGjWq90ALM2XOq7/k71DaVSEb2P0SRvkYTnhC6oljxSIdH 4+4XXtN/mrDa1ExD1gAHMXdV3DfWAvj/IgG0/R5Nx7qwdczWLD2uIVYm2K67dnRAan5n gJ+lHq8zknYxMcsqbACiu9PnxbciiI5vfC4C+E1/6Au/LEVEzNVp+JsNa1ARDkRvrUbV Y7qGrmZTSXjsUsnacsuJlnUWVH1KZA/a8t31vJh4cbyN8YoFQ1SHiIi0kBne1ROSbC0o XAYg== X-Gm-Message-State: ALyK8tK6L3M9UxcaBC8tPbAkkw1bAioAf8t3e6xpI1iZFIyNs+gUOaO5DolsA1sXn+FbnYAzHaK6ht7tkO4i0Q== MIME-Version: 1.0 X-Received: by 10.176.0.146 with SMTP id 18mr4916649uaj.17.1467240425874; Wed, 29 Jun 2016 15:47:05 -0700 (PDT) Received: by 10.103.35.80 with HTTP; Wed, 29 Jun 2016 15:47:05 -0700 (PDT) Received: by 10.103.35.80 with HTTP; Wed, 29 Jun 2016 15:47:05 -0700 (PDT) In-Reply-To: <1467215048.2888.43.camel@intel.com> References: <20160629031255.3551-1-li.zhou@windriver.com> <1467181987.8590.105.camel@linuxfoundation.org> <1467215048.2888.43.camel@intel.com> Date: Wed, 29 Jun 2016 16:47:05 -0600 Message-ID: From: Dan McGregor To: Bill Randle Cc: "openembedded-core@lists.openembedded.org" Subject: Re: [PATCH] python3: correct the multilib support patch X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 22:47:10 -0000 Content-Type: multipart/alternative; boundary=001a114678e8626dfd0536728833 --001a114678e8626dfd0536728833 Content-Type: text/plain; charset=UTF-8 On 29 Jun 2016 9:44 a.m., "Randle, William C" 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 >>> Could not find platform dependent libraries >>> Consider setting $PYTHONHOME to [:] >>> 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 >>> --- >>> ...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 > --001a114678e8626dfd0536728833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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_prefi= x>]
>>> Fatal Python error: Py_Initialize: Unable to get the locale en= coding
>>> ImportError: No module named 'encodings'
>>>
>>> Here correct the rebasing error and solve this issue.
>>>
>>> Signed-off-by: Li Zhou <li.zhou@windriver.com>
>>> ---
>>>=C2=A0 ...ython3-correct-the-multilib-support-patch.patch | 47<= br> >>> ++++++++++++++++++++++
>>>=C2=A0 meta/recipes-devtools/python/python3_3.5.1.bb=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 1 +
>>>=C2=A0 2 files changed, 48 insertions(+)
>>>=C2=A0 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 caug= ht this.
>>
>> Cheers,
>>
>> Richard
>
>
> I would agree that since the original patch has not been accepted upst= ream, =C2=A0it 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&qu= ot;lib/lib-dynload"'. Seems like the second case should use code s= imilar other palces lib-dynload is used in the file that uses lib_python to= build the path.)
>
> =C2=A0 =C2=A0 -Bill

Fedora and others have similar patches. Have people checked = them out?

>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedd= ed-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core=
>

--001a114678e8626dfd0536728833--