1. Building SHR
      1. Dependencies
      2. Before beginning
        1. Hint: check out the Troubleshooting section at the end of this page if …
      3. Set up your local.conf
        1. Hint: It will work without changing anything''
        2. Speed up the building process
        3. Disable/Minimize locales generation
      4. Starting developing
      5. First build
      6. Building an image
      7. Making changes
      8. Updating from other people's changes
      9. Troubleshooting
        1. Unset variables
        2. vala
        3. missing dependency
        4. python-etk
        5. usb-gadget-mode
        6. Please set the 'CACHE' variable
        7. shasum-native
        8. error: C preprocessor arm-angstrom-linux-gnueabi-gcc -E fails sanity check
        9. sato-icon-theme
        10. error: unable to find a register to spill in c
        11. More qemu problems
        12. Can't locate ExtUtils/MakeMaker?.pm
        13. libtool-native
        14. gst-plugins-good fails
        15. fso-specs
        16. /usr/bin/ld: cannot find -lc
      10. Obsolete Troubleshouting
        1. /proc/sys/vm/mmap_min_addr

Building SHR

This page describes how to build you own SHR repository and disk images. We have a [Tinderbox] that shows if the packages have been building correctly on our build host. It might be worth checking if you have problems building a package.

Note: you can track SHR activity on

Dependencies

To run bitbake (make image) some programs are needed to be installed on the buildhost: 

python-2.6, git, svn, cvs, make, gcc, g++, patch, help2man, diffstat, texi2html, bzip2, gawk, tar, md5sum, texinfo, chrpath

Also you need bash to be your default shell.

Before beginning

Download the FSO/SHR Makefile from Bearstech (see README for details): 

$ wget http://shr.bearstech.com/Makefile

Run: 

$ make setup

make setup will download FSO, bitbake and SHR in the shr directory (SHR root directory from now on) and prepare everything for building an image. It takes about 17 minutes (mostly git downloading data, so network-bound).

Hint: check out the Troubleshooting section at the end of this page if you have issues building an image.

Set up your local.conf

Hint: It will work without changing anything''

Before building the image, you might want to update shr-unstable/conf/local.conf to tweak your build. In order to get the right package version, you want to include the following tweaks (which are there by default, please check if you need to modify anything): 

OE_ALLOW_INSECURE_DOWNLOADS=1

Speed up the building process

If your machine has multiple CPU's (or dual-core) this will help: 

PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Disable/Minimize locales generation

To avoid multiple locales generation, add: 

GLIBC_GENERATE_LOCALES = "en_US.UTF-8"

or to disable locale generation at all (Please note, that you can't build an shr image without the en_US.UTF-8 locale, so this is only for building single packages): 

ENABLE_BINARY_LOCALE_GENERATION = "0"

this will also speed up the whole build.

Starting developing

If you are interested in developing SHR application, you should now switch over to Getting started developing SHR

First build

You are now ready to build the SHR image: 

$ cd shr-unstable
$ make image

By default, this will build the image for OM-GTA02. If you want to build the image for OM-GTA01: 

$ cd shr-unstable
$ make setup-machine-om-gta01
$ make image

you can change it back to OM-GTA02 with make setup-machine-om-gta02.

Building an image

When you are satisfied with your changes and want to create a new SHR image: 

$ cd shr-unstable
$ make shr-image or make shr-lite-image

if make shr-lite-image doesn't work, try: 

$ bitbake shr-lite-image

When make process is successfully finished, you can find your fresh image under shr-unstable/tmp/deploy/images.

You will find individual produced packages under shr-unstable/tmp/deploy/ipk/.

Making changes

Make changes to an SHR project (e.g. libphone-ui-shr):

Activate local builds: for this you have to uncomment the following line in shr-unstable/conf/local.conf: 

#require local-builds.inc

Check out the sources of shr-dialer to a directory of your choice (e.g. ~/git): 

git clone http://git.shr-project.org/repo/libphone-ui-shr.git

Then go back to your SHR directory and put the following lines to your shr-unstable/conf/local-builds.inc: 

SRC_URI_pn-libphone-ui-shr = "file:////home/.../git/${PN}"
SRCREV_pn-libphone-ui-shr = "LOCAL"                         # or any other SRCREV of your choice
SRCPV_pn-libphone-ui-shr = "LOCAL"
S_pn-libphone-ui-shr = "${WORKDIR}/${PN}"

Now start building the package to verify that you have a correct base version and a working development environment: 

$ cd shr-unstable
$ . ./setup-env                      # only once per session
$ bitbake -c clean libphone-ui-shr
$ bitbake libphone-ui-shr

If something fails check the logfiles shr-unstable/tmp/work/armv4t-oe-linux-gnuabi/libphone-ui-shr-.0.0.0+gitrLOCAL-r*/temp. Do make your changes in your base directory, not in the temp working directories they might get lost, and then clean/build.

There is no need to check-in the changes to the SHR repo, because the system now looks for SHR packages in the local filesystem. The problem is that it is necessary to always clean the packages so bitbake gets the new changes next time you compile, or change the SRCREV to a higher version.

If the scanning of all the bitbake recipes is too slow for you use the interactive mode: 

$ cd shr-unstable
$ . ./setup-env                      # only once per session
$ bitbake -i
BB>>rebuild libphone-ui-shr

Bitbake rebuild does both a clean and a build, all other steps can also be run individually from the prompt.

Updating from other people's changes

If you want to update everything (SHR-unstable, SHR-testing and bitbake), from the top directory: 

$ make update

Or for just shr-unstable, from the top directory: 

$ make update-shr-unstable

Or under the shr-unstable/openembedded directory: 

$ git pull

Troubleshooting

Unset variables

One thing to try is to unset all environment variables not listed in this page. LIBPATH and INCLUDE can be particularly troublesome.

vala

Note: Unless you have valac on your build box, you're bound to run into trouble with vala-native. To work around this, do: bitbake -c clean vala-bootstrap-native; bitbake vala-bootstrap-native. Then vala-native should bitbake ok, allowing image to be built.

(btw. if you bitbake vala-native and you want to bitbake it again, you have to explicitly clean and rebake vala-bootstrap-native)

missing dependency

Note: it's highly probable that the build will fail due to a missing dependency, fso-abyss: you will have to execute "bitbake fso-abyss" manually inside the shr-unstable folder in order to get it built, and retry the image building.

python-etk

As of 16th january 2008, if python-etk fails, re-open OE #4992. workaround try this: 

$ bitbake -c clean python-etk; bitbake eina; bitbake python-etk

usb-gadget-mode

If usb-gadget-mode fails building, try this: 

$ echo 'MACHINE_CLASS = "armv4t"' >> common/conf/site.conf

Please set the 'CACHE' variable

If you get the error 'Please set the 'CACHE' variable', try to edit /usr/share/bitbake/conf/bitbake.conf and add: 

CACHE = "~/your/path/somedir"

shasum-native

If build fails on "openembedded/packages/shasum/shasum-native.bb, do_compile" with empty log and you aren't using debian it's probably 'ccache' fault. Try one of these: 

$ echo 'export HOME = "'$HOME'"' >> openembedded/conf/bitbake.conf 
$ echo 'CCACHE = ""' >> conf/local.conf

error: C preprocessor arm-angstrom-linux-gnueabi-gcc -E fails sanity check

If build fails on "do_configure" with "configure: error: C preprocessor arm-angstrom-linux-gnueabi-gcc -E fails sanity check", run: 

$ bitbake -c clean eglibc eglibc-initial && bitbake eglibc eglibc-initial

sato-icon-theme

If build fails on sato-icon-theme with "ERROR: Could not include required file /mnt/loop/shr-testing/openembedded/packages/sato-icon-theme/sato-icon-theme.inc", edit the the sato-icon-theme.inc file, and comment out the first line, which includes itself. (??!)

error: unable to find a register to spill in c

If build fails on qemu-native (in do_compile of glibc) with "error: unable to find a register to spill in c lass `GENERAL_REGS'", cd to shr-testing/tmp/work/i686-linux/qemu-native-0.9.1+svnr4242-r14/trunk, edit 'configure', find 'gcc3_list' variable and put gcc-3.3 before all others, then e.g. ./configure and make by hand.

More qemu problems

If you can't get qemu to build, you can also try adding the following to shr-unstable/conf/local.conf: 

ASSUME_PROVIDED += "qemu-native"

You will then need to natively install the qemu-arm binary on your build host (should be in the qemu package).

Can't locate ExtUtils/MakeMaker?.pm

If build fails on git-native with "Can't locate ExtUtils/MakeMaker?.pm ..." in the Log, you need to install the package "perl-ExtUtils?-MakeMaker?" on your buildhost.

libtool-native

If libtool-native fails in do_compile with: "source directory already configured": The cause can be a symlink in your TOPDIR variable (this then propagates to OE) - check conf/topdir.conf.

gst-plugins-good fails

Open openembedded/recipes/gstreamer/gst-plugins-good_0.10.17.bb add to EXTRA_OECONF --disable-esd Terminal: . ./setup-env bitbake -c configure gst-plugins-good bitbake -c rebuild gst-plugins-good make image

fso-specs

If build fails with "..../fso-specs_git.bb do_compile failed" check whether xsltproc is installed. In ubuntu it can be installed via: 

$ sudo apt-get install xsltproc

/usr/bin/ld: cannot find -lc

If build fails on module-init-tools-cross with "/usr/bin/ld: cannot find -lc" check whether you have libc static library installed. In Debian/Ubuntu libc6-dev package should provide it. In Fedora, install glibc-static package.

Obsolete Troubleshouting

/proc/sys/vm/mmap_min_addr

Obsolete as this isn't required anymore by newer qemu

If you get the error '/proc/sys/vm/mmap_min_addr is not 0', try 

$ echo 0 | sudo tee /proc/sys/vm/mmap_min_addr

(That's a bad idea, because of this linux kernel bug http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html so better deactivate sanity check by touching conf/sanity.conf)