Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "Randle, William C" <william.c.randle@intel.com>
To: "richard.purdie@linuxfoundation.org"
	<richard.purdie@linuxfoundation.org>,
	 "Zhou, Li (Wind River)" <li.zhou@windriver.com>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] python3: correct the multilib support patch
Date: Wed, 29 Jun 2016 15:44:08 +0000	[thread overview]
Message-ID: <1467215048.2888.43.camel@intel.com> (raw)
In-Reply-To: <1467181987.8590.105.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

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<mailto: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

[-- Attachment #2: Type: text/html, Size: 2391 bytes --]

  reply	other threads:[~2016-06-29 15:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-29  3:12 [PATCH] python3: correct the multilib support patch Li Zhou
2016-06-29  6:33 ` Richard Purdie
2016-06-29 15:44   ` Randle, William C [this message]
2016-06-29 22:47     ` Dan McGregor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1467215048.2888.43.camel@intel.com \
    --to=william.c.randle@intel.com \
    --cc=li.zhou@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox