BuildingOnRHEL4

From Yocto Project
Revision as of 23:28, 29 March 2011 by Madison (talk | contribs)
Jump to navigationJump to search

This page contains notes on getting Yocto builds going on an RHEL 4-based build host.

My RHEL 4 system includes these versions of packages, which appear to have some effect on builds:

  • Kernel 2.6.9-89.0.11.EL
    No KVM support installed, so cannot build qemu-native
    Also causes pseudo-native build problems, due to older definition of clone()
  • make 3.80-7.EL4
    util-linux builds fail with this version of make; need 3.81.
    Tried using the make-native recipe, which provides make 3.82. However, eglibc-initial fails in the install step when using make 3.82.
  • gcc 3.4.6-11
    Does not support the -Wno-pointer-signed option, causing prelink-native to fail to compile
  • binutils 2.15.92.0.2-25
  • python 2.3.4-14.7.el4_8.2
    Too old a version for bitbake; needs 2.6 or 2.7
  • coreutils 5.2.1-36.el4
    The install utility in this version does not support '-t', causing the linux-yocto install_perf task to fail. Looks like support for '-t' was added in 5.3.
  • glibc 2.3.4-2.43.el4_8.3
    No inotify support (added in glibc 2.4), which breaks dbus-native builds
    Also causes pseudo-native build problems, due to change in type of return value for readlink()

This was a 64-bit system, also (x86_64).

Bootstrapping

I don't have root or sudo access on my system, so I had to bootstrap the hard way, pulling source tarballs and building the following from scratch.

  1. sqlite 3.7.5
  2. Python 2.7.1
  3. git 1.7.4
  4. chrpath 0.13

No special configuration used, other than setting --prefix= to point to a directory I owned. You must build sqlite before Python to get the sqlite Python module to build. I ignored the failures to build other Python modules, and that seems to be OK.

I already had a pre-built version of make 3.81 available, otherwise I would have had to build that as well.

Now with git, chrpath, and the just-built version of python in my PATH:

  1. Fetch the poky.git sources
  2. Do the normal poky-init-build-env to set up a build directory
  3. Edit $BUILDDIR/conf/local.conf:
    Remove image-prelink from USER_CLASSES
    Set ENABLE_BINARY_LOCALE_GENERATION to "0" (depends on qemu-native, which won't build)
    Added ASSUME_PROVIDED += "qemu-native" just to be sure that qemu-native build won't be attempted
    Added PATH_prepend = "/path/to/my/private/bin" to point to where I have the tools mentioned above installed.

Next, I added two patches:

  • One to pseudo to account for the difference in clone() and readlink().
  • One to meta/recipes-core/dbus/dbus.inc to add --disable-dnotify to EXTRA_OECONF.

Next, I built coreutils-native, and put a copy of install in my private bin directory:

$ cp tmp/sysroots/x86_64/usr/bin/install.coreutils /path/to/my/private/bin/install

Done. At this point, I can now build a poky-image-minimal image for qemux86, qemuarm, qemumips, or qemuppc.

Building a -sato image

  1. The libcap cross-build creates a program on the build host that fails to build unless the glibc-kernheaders package is installed. Since I didn't have that, and I don't have the privileges to install it myself, I grabbed a copy from my local yum repository and installed the headers in my private root. I then added to my local.conf:
    BUILD_CFLAGS =+ "-isystem /path/to/my/private/include"
  2. The mesa-dri configure step looks for a valid (native) Python executable by looking for 'python2' before 'python'. On my system, this caused it to pick up the ancient Python in /usr/bin, since it had a 'python2' symlink installed there, whereas the python-native build did not put one in the native sysroot. I worked around this by creating one in the native sysroot.

With the above additional workarounds, I was able to build a poky-image-sato image for qemux86.

Note that this is building off the head of the bernard branch as of 22 March 2011.