Multilib related postinstall fixes

There is still work to do on the multilib postinstalls running on host front. This is a first patchset trying to address some of the issues.

Thanks,
Laurentiu

The following changes since commit addcfcda84ed6b43b00f569a6060e3b78196ef52:

glib-2.0: disable tests for native builds, and respect ptest for LSB (2013-04-23 13:00:43 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib lpalcu/ml_postinstall_fixes
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/ml_postinstall_fixes

Laurentiu Palcu (4):
qemuwrapper: use fallback in case the ELF binary is wrong
pango: fix postinstall when using multilib
Revert "qemu.bbclass: Use the correct qemu binary in multilib cases" scripts/postinst-intercepts: create separete hooks for multilib

 meta/classes/qemu.bbclass                          |    4 +--
 .../recipes-devtools/qemu/qemuwrapper-cross_1.0.bb |   28 +++++++++++++++++++-
 meta/recipes-graphics/pango/pango.inc              |    2 +-
 scripts/postinst-intercepts/postinst_intercept     |   18 +++++++++++++
 4 files changed, 47 insertions(+), 5 deletions(-)

1.7.9.5

This wrapper script is called mainly from intercept hooks and allarch packages postinstalls. When multilib is used, the qemuwrapper script points to the binary that matches the MACHINE architecture.

For example: if MACHINE=qemux86_64 and we activate multilib, then the postinstalls for lib32 packages would call qemu-x86_64 with 32 bit binaries and they would certainly fail.

This patch adds just a fallback method if the exit code of the previous qemu call corresponds to "Invalid ELF image for this architecture" error. This will allow us to have all postinstalls run on host.

---
 .../recipes-devtools/qemu/qemuwrapper-cross_1.0.bb |   28 +++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

index 41617a6..18f1892 100644
@@ -9,7 +9,33 @@ do_install () {
 	install -d ${D}${bindir_crossscripts}/
 
 	echo "#!/bin/sh" > ${D}${bindir_crossscripts}/qemuwrapper
-	echo exec env ${@qemu_target_binary(d)} \"\$@\" >> ${D}${bindir_crossscripts}/qemuwrapper
+	qemu_binary=${@qemu_target_binary(d)}
+	echo "$qemu_binary \"\$@\"" >> ${D}${bindir_crossscripts}/qemuwrapper
+	fallback_qemu_bin=
+	case $qemu_binary in
+		"qemu-i386")
+			fallback_qemu_bin=qemu-x86_64
+			;;
+		"qemu-x86_64")
+			fallback_qemu_bin=qemu-i386
+			;;
+		*)
+			;;
+	esac
+
+	if [ -n "$fallback_qemu_bin" ]; then
+
+		cat >> ${D}${bindir_crossscripts}/qemuwrapper << EOF
+rc=\$?
+if [ \$rc = 255 ]; then
+	$fallback_qemu_bin "\$@"
+	rc=\$?
+fi
+exit \$rc
+EOF
+
+	fi
+
 	chmod +x ${D}${bindir_crossscripts}/qemuwrapper
 }
 

1.7.9.5

The pango-query-modules binary gets a multilib prefix and the postinstall has to call the appropriate binary.

---
 meta/recipes-graphics/pango/pango.inc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index f622903..52dd064 100644
@@ -49,7 +49,7 @@ if ! [ -e $D${sysconfdir}/pango ] ; then
 fi
 
 if [ "x$D" != "x" ]; then
-	${@qemu_run_binary(d, '$D','/usr/bin/pango-querymodules')} \
+	${@qemu_run_binary(d, '$D','${bindir}/${MLPREFIX}pango-querymodules')} \
 		$D${libdir}/pango/${LIBV}/modules/*.so \
 		> $D${sysconfdir}/pango/${MLPREFIX}pango.modules 2>/dev/null
 

1.7.9.5

This reverts commit 9f5a6f89d9f4a6c7bed3b163e6eaa764d762f523.

The reason for reverting this is:
* qemuwrapper has now a fallback method;
* when using multilib, calling qemu_target_binary from recipes would always point to the qemu binary corresponding to the machine architecture. Hence, postinstalls needing to use qemu would call the wrong qemu user emulation binary;

---
 meta/classes/qemu.bbclass |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

index 930c6b0..3d437b0 100644
@@ -4,9 +4,7 @@
 #
 
 def qemu_target_binary(data):
-    target_arch = data.getVar("TARGET_ARCH_MULTILIB_ORIGINAL", True)
-    if not target_arch:
-        target_arch = data.getVar("TARGET_ARCH", True)
+    target_arch = data.getVar("TARGET_ARCH", True)
     if target_arch in ("i486", "i586", "i686"):
         target_arch = "i386"
     elif target_arch == "powerpc":

1.7.9.5

When using multilib, the hooks for lib32/lib64 must be different because the libdir/base_libdir point to different locations. Nothing has to be done in the postinstalls for this. When a hook is installed, it will be detected automatically if this is a ML package (from the libXX- package prefix) and a separate hook will be created.

---
 scripts/postinst-intercepts/postinst_intercept |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

index ed32f27..5969eba 100755
@@ -17,9 +17,27 @@
 
 intercept_script=$INTERCEPT_DIR/$1 && shift
 package_name=$1 && shift
+mlprefix=$(echo $package_name|sed -rn 's/^(lib32|lib64|libx32)-.*/\1/p')
 
+# if the hook we want to install does not exist, then there's nothing we can do
 [ -f "$intercept_script" ] || exit 1
 
+# if the postinstall wanting to install the hook belongs to a multilib package,
+# then we'd better have a separate hook for this because the default ${libdir} and
+# ${base_libdir} will point to the wrong locations
+if [ -n "$mlprefix" ]; then
+	ml_intercept_script=$intercept_script-$mlprefix
+	# if the multilib hook does not exist, create it from the default one
+	if [ ! -f "$ml_intercept_script" ]; then
+		cp $intercept_script $ml_intercept_script
+
+		# clear the ##PKGS: line and the already set variables
+		[ -x "$ml_intercept_script" ] && sed -i -e "2,$(($#+1)) {/.*/d}" -e "/^##PKGS: .*/d" $ml_intercept_script
+	fi
+
+	intercept_script=$ml_intercept_script
+fi
+
 chmod +x "$intercept_script"
 
 pkgs_line="$(cat $intercept_script|grep "##PKGS:")"

1.7.9.5

OK, I understand your concern... I could probably pass mlprefix=${MLPREFIX} as a third argument to all calls to postinst_intercept script instead. I'll rework it and send a v2.

Thanks,
Laurentiu