Skip to contentSkip to conversation

Misc fixes

PATCH In review Mark Hatle 2 participants 6 messages Nov 25, 2015

lore
Share & tools
lore

Mark Hatle

author
#0 lore raw

cover Misc fixes

The following fixes have been tested on Jethro, I believe they are also applicable on master.

Note that the python change fixes an illegal instruction problem -- but in some of my testing has exposed a second issue where 'unsafe' include/lib dir warnings are present. I'm still working with others for a solution to that.

Mark Hatle (3):
allarch.bbclass: allarch packages are having their hashes altered by
baselib
python: Fix cross compiling x86->x86
package_manager.py: Avoid installing an empty package list

 meta/classes/allarch.bbclass                       |  5 +++++
 meta/lib/oe/package_manager.py                     |  3 +++
 .../use-CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch | 23 ++++++++++++++++++++++
 meta/recipes-devtools/python/python_2.7.9.bb       |  4 ++--
 4 files changed, 33 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/python/python/use-CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch
Signature · 1 line
1.9.3
author
#1 lore raw

PATCH 1/3 allarch.bbclass: allarch packages are having their hashes altered by baselib

In a multilib configuration baselib can change, but allarch packages should not changed from multilib to multilib. So we set the value of baselib to none which should act as a market for any errant users of libdir. nonarch_base_libdir / nonarch_libdir should be used instead.

---
 meta/classes/allarch.bbclass | 5 +++++
 1 file changed, 5 insertions(+)
meta/classes/allarch.bbclass +5 -0
index 2fea7c0..6fa7a23 100644
@@ -28,6 +28,11 @@ python () {
         d.setVar("SDK_ARCH", "none")
         d.setVar("SDK_CC_ARCH", "none")
 
+        # In a multilib configuration baselib can change, but we shouldn't be
+        # using it anyway.  All packages should use nonarch_base_libdir or 
+        # nonarch_libdir.
+        d.setVar("baselib", "none")
+
         # Avoid this being unnecessarily different due to nuances of
         # the target machine that aren't important for "all" arch
         # packages.
Signature · 1 line
1.9.3
author
#2 lore raw

PATCH 2/3 python: Fix cross compiling x86->x86

In reply to Mark Hatle

If the target and host have the same type, the system may try to execute the instructions from the target version. This can lead to illegal instructions as well as the wrong copy of the code running.

---
 .../use-CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch | 23 ++++++++++++++++++++++
 meta/recipes-devtools/python/python_2.7.9.bb       |  4 ++--
 2 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/python/python/use-CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch
meta/recipes-devtools/python/python/use-CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch new file +23 -0
new file mode 100644
index 0000000..3c44cc0
@@ -0,0 +1,23 @@
+configure.ac: use CROSSPYTHONPATH instead of a static list
+
+When building x86->x86 the system will try to execute .so and related items
+from the default PYTHONPATH.  This will fail if the target CPU contains
+instructions that the host CPU does not have.
+
+Upstream-Status: Inappropriate [OE-Core integration specific]
+
+Signed-off-by: Mark Hatle <[email protected]>
+
+Index: Python-2.7.9/configure.ac
+===================================================================
+--- Python-2.7.9.orig/configure.ac
++++ Python-2.7.9/configure.ac
+@@ -33,7 +33,7 @@ if test "$cross_compiling" = yes; then
+ 	    AC_MSG_ERROR([python$PACKAGE_VERSION interpreter not found])
+ 	fi
+         AC_MSG_RESULT($interp)
+-	PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib:$(srcdir)/Lib/plat-$(MACHDEP) '$interp
++	PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(CROSSPYTHONPATH) '$interp
+     fi
+ elif test "$cross_compiling" = maybe; then
+     AC_MSG_ERROR([Cross compiling required --host=HOST-TUPLE and --build=ARCH])
meta/recipes-devtools/python/python_2.7.9.bb +2 -2
index f7e2f27..183f715 100644
@@ -26,6 +26,7 @@ SRC_URI += "\
   file://parallel-makeinst-create-bindir.patch \
   file://use_sysroot_ncurses_instead_of_host.patch \
   file://avoid_parallel_make_races_on_pgen.patch \
+  file://use-CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch \
 "
 
 S = "${WORKDIR}/Python-${PV}"
@@ -38,6 +39,7 @@ CONFIGUREOPTS += " --with-system-ffi "
 #Somehow gcc doesn't set __SOFTFP__ when passing -mfloatabi=softp :(
 TARGET_CC_ARCH_append_armv6 = " -D__SOFTFP__"
 TARGET_CC_ARCH_append_armv7a = " -D__SOFTFP__"
+EXTRA_OECONF += "CROSSPYTHONPATH=${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dynload/"
 
 # The following is a hack until we drop ac_cv_sizeof_off_t from site files
 EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 'ac_cv_sizeof_off_t=8', '', d)} ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no"
@@ -101,7 +103,6 @@ do_install() {
 	# install can race with the build so we have to run this first, then install
 	oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/python-native/pgen \
 		HOSTPYTHON=${STAGING_BINDIR_NATIVE}/python-native/python \
-		CROSSPYTHONPATH=${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dynload/ \
 		STAGING_LIBDIR=${STAGING_LIBDIR} \
 		STAGING_INCDIR=${STAGING_INCDIR} \
 		STAGING_BASELIBDIR=${STAGING_BASELIBDIR} \
@@ -110,7 +111,6 @@ do_install() {
 	
 	oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/python-native/pgen \
 		HOSTPYTHON=${STAGING_BINDIR_NATIVE}/python-native/python \
-		CROSSPYTHONPATH=${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dynload/ \
 		STAGING_LIBDIR=${STAGING_LIBDIR} \
 		STAGING_INCDIR=${STAGING_INCDIR} \
 		STAGING_BASELIBDIR=${STAGING_BASELIBDIR} \
Signature · 1 line
1.9.3
author
#3 lore raw

PATCH 3/3 package_manager.py: Avoid installing an empty package list

In reply to Mark Hatle

It is possible in an attempt only install, that everything listed is not available to be installed. This will have the effect of clearing the package list. However, we only check for an empty package list at the beginning of the function. We need to also check before running the install, otherwise we can fail due to 'error: no package(s) given".

---
 meta/lib/oe/package_manager.py | 3 +++
 1 file changed, 3 insertions(+)
meta/lib/oe/package_manager.py +3 -0
index 36bd29f..2483e97 100644
@@ -1171,6 +1171,9 @@ class RpmPM(PackageManager):
                     new_depends[new_depend] = deps[depend]
                 pkgs = bb.utils.join_deps(new_depends, commasep=True).split(', ')
         pkgs = self._pkg_translate_oe_to_smart(pkgs, attempt_only)
+        if not pkgs:
+            bb.note("There are no packages to install")
+            return
         if not attempt_only:
             bb.note('to be installed: %s' % ' '.join(pkgs))
             cmd = "%s %s install -y %s" % \
Signature · 1 line
1.9.3
#4 lore raw
In reply to Mark Hatle
Quoted 3 lines · Mark Hatle

The following fixes have been tested on Jethro, I believe they are also applicable on master.

As we generally want to ensure fixes go to master before jethro, can you rebase these to master (at least 1 and 2 don't apply anymore).

Also is the python2 fix applicable to python3 too?

Ross

author
#5 lore raw
Quoted 10 lines · Ross

On 25 November 2015 at 20:44, Mark Hatle <[email protected] <mailto:[email protected]>> wrote:

The following fixes have been tested on Jethro, I believe they are also applicable on master.

As we generally want to ensure fixes go to master before jethro, can you rebase these to master (at least 1 and 2 don't apply anymore).

Luckily master hasn't deviated much. But honestly, I don't have time to rebase right now. Next week would likely be the earliest.

Quoted 1 line

Also is the python2 fix applicable to python3 too?

The python2 fix was derived from the fix python3 already had.

HOWEVER, we've found conditions where it breaks python2. So it should not be applied.

There is still a host contamination issue that needs to be resolved, but I don't have any idea of a fix.

Quoted 1 line

Ross