HAL and external toolchain

While building an extended filesystem for my project, using an external toolchain/SDK, I found out that recent hal recipe in OpenEmbedded fails to build. It appears that hal uses a linux/input.h header file from glibc installation for its own configuration. Normally, glibc headers are installed in the staging area by corresponding -cross recipes. That's where hal recipe was trying to find it, which is not the case with the external toolchain:

EXTRA_OECONF += "--with-linux-input-header=${STAGING_INCDIR}/linux/input.h"

After some investigation and a short discussion on the oe-dev mailing list (with help from core developers Holger Freyther and Koen Kooi), I was able to create patches to the hal recipe, allowing it to be built by an external toolchain/SDK:

From 507ee230617603258736ecbcf4895de5429f8672 Mon Sep 17 00:00:00 2001
From: Denys Dmytriyenko 
Date: Mon, 10 Nov 2008 20:13:22 -0500
Subject: [PATCH] autotools.bbclass: allow autotools_do_configure to accept parameters and pass to oe_runconf


Signed-off-by: Denys Dmytriyenko 
---
 classes/autotools.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index 82b5311..adb57f6 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -134,7 +134,7 @@ autotools_do_configure() {
  ;;
  esac
  if [ -e ${S}/configure ]; then
-  oe_runconf
+  oe_runconf $@
  else
   oenote "nothing to configure"
  fi
-- 
1.5.6.4

From 1a568f9490eb7bfd1060f47e2584d3ce41820b6b Mon Sep 17 00:00:00 2001
From: Denys Dmytriyenko 
Date: Mon, 10 Nov 2008 20:17:02 -0500
Subject: [PATCH] hal: Find and use the right linux/input.h to work with external toolchain


Signed-off-by: Denys Dmytriyenko 
---
 packages/hal/hal_0.5.11.bb |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/packages/hal/hal_0.5.11.bb b/packages/hal/hal_0.5.11.bb
index e93ad64..2b56fdf 100644
--- a/packages/hal/hal_0.5.11.bb
+++ b/packages/hal/hal_0.5.11.bb
@@ -1,8 +1,14 @@
 require hal.inc
 
-PR = "r1"
+PR = "r2"
 
 SRC_URI += " file://hal-right-input-h.patch;patch=1 \
              file://fix-configure.diff;patch=1"
 
-EXTRA_OECONF += "--with-linux-input-header=${STAGING_INCDIR}/linux/input.h"
+# The following code finds the right linux/input.h,
+# which also works with external-toolchain/SDK
+do_configure() {
+ linux_input_h=`echo "#include " | ${CPP} - | \
+  grep "linux\/input.h" | head -n 1 | awk -F '"' '{print $2}'`
+ autotools_do_configure --with-linux-input-header=${linux_input_h}
+}
-- 
1.5.6.4

DPF - my side project using OE

I have been looking into ways to utilize an old laptop, which been sitting on a shelf collecting dust for quite some time. One of the ideas was to convert it into a digital picture frame. There are many such projects explained on the Internet and specifically at Instructables. First, since the laptop had no hard drive in it, I needed a Compact Flash card with a CF-to-IDE converter. Luckily I had both and the next step was to think about the software.

The obvious choice was to use OpenEmbedded to build a small filesystem with necessary components to access my pictures from the fileserver (hopefully wirelessly...). That's one of the things I don't like about most of the DPF products available on the market - they can only load images from local storage or from flash cards. There are few WiFi-enabled picture frames, but they are limited and expensive. Since I have all of the required hardware components and necessary knowledge (I hope) to build a nice WiFi-enabled digital picture frame myself, I jumped right into this DIY project.

Since the laptop I was going to use is a PentiumIII based, I tried to build a minimal image for an i686 architecure. That's where I hit a snag - apparently, glibc refuses to build for any of the i686, pentiumpro or pentium3 architectures and it's been discussed a lot. Not sure about the actual reason it was never fixed in glibc, I was able to find a patch for eglibc from Khem Raj, which happened to apply to glibc as well. I have opened a bug ticket and emailed to the list (see below).

Now I'm able to build stuff for my future digital picture frame...

diff --git a/packages/glibc/files/march-i686.patch b/packages/glibc/files/march-i686.patch
new file mode 100644
index 0000000..0461603
--- /dev/null
+++ b/packages/glibc/files/march-i686.patch
@@ -0,0 +1,38 @@
+2007-02-15  Khem Raj  
+
+       * sysdeps/unix/sysv/linux/i386/sysdep.h: Re-define __i686.
+       * nptl/sysdeps/pthread/pt-initfini.c: Ditto.
+
+
+
+Index: sysdeps/unix/sysv/linux/i386/sysdep.h
+===================================================================
+--- sysdeps/unix/sysv/linux/i386/sysdep.h (revision 1469)
++++ sysdeps/unix/sysv/linux/i386/sysdep.h (working copy)
+@@ -29,6 +29,10 @@
+ #include 
+ #include 
+ 
++#if defined __i686 && defined __ASSEMBLER__
++#undef __i686
++#define __i686 __i686
++#endif
+ 
+ /* For Linux we can use the system call table in the header file
+  /usr/include/asm/unistd.h
+Index: nptl/sysdeps/pthread/pt-initfini.c
+===================================================================
+--- nptl/sysdeps/pthread/pt-initfini.c (revision 1469)
++++ nptl/sysdeps/pthread/pt-initfini.c (working copy)
+@@ -45,6 +45,11 @@
+ /* Embed an #include to pull in the alignment and .end directives. */
+ asm ("\n#include \"defs.h\"");
+ 
++asm ("\n#if defined __i686 && defined __ASSEMBLER__");
++asm ("\n#undef __i686");
++asm ("\n#define __i686 __i686");
++asm ("\n#endif");
++
+ /* The initial common code ends here. */
+ asm ("\n/*@HEADER_ENDS*/");
+ 
diff --git a/packages/glibc/glibc_2.6.1.bb b/packages/glibc/glibc_2.6.1.bb
index 1f72ff0..a6e2dd4 100644
--- a/packages/glibc/glibc_2.6.1.bb
+++ b/packages/glibc/glibc_2.6.1.bb
@@ -58,6 +58,7 @@ SRC_URI = "\
   file://glibc-use-isystem-include-fixed.patch;patch=1 \
   file://glibc-arm-no-asm-page.patch;patch=1 \
   file://armv4t-interworking.patch;patch=1 \
+  file://march-i686.patch;patch=1;pnum=0 \
 "
 
 # Build fails on sh3 and sh4 without additional patches