[PATCH V2 0/1] fix python3 do_configure failed on meta-fsl-ppc with MACHINE = "p1022ds"

[PATCH V2 0/1] fix python3 do_configure failed on meta-fsl-ppc with MACHINE = "p1022ds"

[Hongxu Jia]

Changed in V1: Fix python3 rather than gcc-cross to minimize the influence.

//Hongxu

The following changes since commit 37b61b059031e3c272a929b834e12fd83f46598c:

  siteinfo: Add ppc64le support. (2016-03-10 23:13:55 +0000)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib hongxu/fix-python3-gcc
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=hongxu/fix-buildpath

Hongxu Jia (1):
  python3: fix do_configure check platform triplet error

 .../tweak-MULTIARCH-for-powerpc-linux-gnuspe.patch | 52 ++++++++++++++++++++++
 meta/recipes-devtools/python/python3_3.5.1.bb      |  1 +
 2 files changed, 53 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3/tweak-MULTIARCH-for-powerpc-linux-gnuspe.patch

-- 
1.9.1

[PATCH 1/1] python3: fix do_configure check platform triplet error

[Hongxu Jia]

For p1022ds bsp, the MULTIARCH is powerpc-linux-gnuspev1 and
python3 did not recognize the extra 'v1' which caused python3
configure error for the platform triplet.

Q:Why Python3 check platform triplet?

A:Under Linux, GNU/KFreeBSD and the Hurd, C extensions now include
the architecture triplet in the extension name, to make it easy to
test builds for different ABIs in the same working tree.

vim config.log
...
EXT_SUFFIX='.cpython-35m-powerpc-linux-gnuspe.so'
...

Here is the generated C extensions which take platform triplet into account.
...
|image/usr/lib/python3.5/lib-dynload/_datetime.cpython-35m-powerpc-linux-gnuspe.so
...

https://bugs.python.org/issue22980
https://www.python.org/dev/peps/pep-3149/
https://bugs.python.org/review/22980/patch/14593/54808

[YOCTO #9226]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 .../tweak-MULTIARCH-for-powerpc-linux-gnuspe.patch | 52 ++++++++++++++++++++++
 meta/recipes-devtools/python/python3_3.5.1.bb      |  1 +
 2 files changed, 53 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3/tweak-MULTIARCH-for-powerpc-linux-gnuspe.patch

diff --git a/meta/recipes-devtools/python/python3/tweak-MULTIARCH-for-powerpc-linux-gnuspe.patch b/meta/recipes-devtools/python/python3/tweak-MULTIARCH-for-powerpc-linux-gnuspe.patch
new file mode 100644
index 0000000..8d03727
--- /dev/null
+++ b/meta/recipes-devtools/python/python3/tweak-MULTIARCH-for-powerpc-linux-gnuspe.patch
@@ -0,0 +1,52 @@
+From 5d6509313198ec9b686cad50b002212e4344004b Mon Sep 17 00:00:00 2001
+From: Hongxu Jia <hongxu.jia@windriver.com>
+Date: Fri, 11 Mar 2016 01:15:45 -0500
+Subject: [PATCH] configure.ac: tweak MULTIARCH for powerpc-linux-gnuspe
+
+For p1022ds bsp, the MULTIARCH is powerpc-linux-gnuspev1 and
+python3 did not recognize the extra 'v1' which caused python3
+configure error for the platform triplet.
+
+Q:Why Python3 check platform triplet?
+
+A:Under Linux, GNU/KFreeBSD and the Hurd, C extensions now include
+the architecture triplet in the extension name, to make it easy to
+test builds for different ABIs in the same working tree.
+
+Here is the generated  C extensions which take platform triplet into account.
+...
+|image/usr/lib/python3.5/lib-dynload/_datetime.cpython-35m-powerpc-linux-gnuspe.so
+...
+
+https://bugs.python.org/issue22980
+https://www.python.org/dev/peps/pep-3149/
+https://bugs.python.org/review/22980/patch/14593/54808
+
+Upstream-Status: Pending
+
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ configure.ac | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 9eb3d22..c34a9a0 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -724,6 +724,13 @@ fi
+ 
+ 
+ MULTIARCH=$($CC --print-multiarch 2>/dev/null)
++
++# Tweak MULTIARCH
++if test x$MULTIARCH = xpowerpc-linux-gnuspev1
++then
++	MULTIARCH="powerpc-linux-gnuspe"
++fi
++
+ AC_SUBST(MULTIARCH)
+ 
+ AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])
+-- 
+1.9.1
+
diff --git a/meta/recipes-devtools/python/python3_3.5.1.bb b/meta/recipes-devtools/python/python3_3.5.1.bb
index 11f959b..2fbb3cb 100644
--- a/meta/recipes-devtools/python/python3_3.5.1.bb
+++ b/meta/recipes-devtools/python/python3_3.5.1.bb
@@ -17,6 +17,7 @@ file://110-enable-zlib.patch \
 file://130-readline-setup.patch \
 file://150-fix-setupterm.patch \
 file://0001-h2py-Fix-issue-13032-where-it-fails-with-UnicodeDeco.patch \
+file://tweak-MULTIARCH-for-powerpc-linux-gnuspe.patch \
 ${DISTRO_SRC_URI} \
 "
 
-- 
1.9.1

Re: [PATCH 1/1] python3: fix do_configure check platform triplet error

[Burton, Ross]

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

On 11 March 2016 at 07:40, Hongxu Jia <hongxu.jia@windriver.com> wrote:

> For p1022ds bsp, the MULTIARCH is powerpc-linux-gnuspev1 and
> python3 did not recognize the extra 'v1' which caused python3
> configure error for the platform triplet.
>

Forgive me for dry-by commenting without a lot of clue about this, but
doesn't that suggest instead that the C function to emit the triplets is in
fact wrong?

Ross

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

Re: [PATCH 1/1] python3: fix do_configure check platform triplet error

[Richard Purdie]

On Fri, 2016-03-11 at 09:04 +0000, Burton, Ross wrote:
> 
> On 11 March 2016 at 07:40, Hongxu Jia <hongxu.jia@windriver.com>
> wrote:
> > For p1022ds bsp, the MULTIARCH is powerpc-linux-gnuspev1 and
> > python3 did not recognize the extra 'v1' which caused python3
> > configure error for the platform triplet.
> > 
> Forgive me for dry-by commenting without a lot of clue about this,
> but doesn't that suggest instead that the C function to emit the
> triplets is in fact wrong?

Following the links does give more context. The "bad" triplet is
actually coming from gcc and Hongxu's original patch did change gcc to
"fix" it. Unfortunately it does so at the risk of other problems to
gcc.

The gcc-cross recipes aren't working entirely correctly at the moment
and its just good luck (and sstate) which are meaning things do
actually work out.

The trouble is that changing gcc right now to fix this properly isn't
something we can easily do. So this patch might be the right short term
workaround.

Cheers,

Richard