wiki:Building_SHR_old

Version 84 (modified by nschle85, 9 years ago) (diff)

moved eve build troubleshooting to obsolete

Building SHR

This page describes how to build you own SHR repository and disk images. We have a http://tinderbox.openembedded.net/builders/shr.bearstech.com/ 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:

libtool, 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 shr-project (see README for details):

$ wget http://build.shr-project.org/Makefile

Optionally you can use provided minimal chroot environment:

$ make setup-shr-chroot
$ # on 64bit systems or
$ make setup-shr-chroot-32bit
$ # but be aware that 64bit version is used by most SHR devs so it's updated more often and better tested

make setup-shr-chroot will checkout shr-chroot repository to shr-chroot directory (mostly git downloading data, so network-bound). And it will also change UID/GID of included bitbake account from default 1026 to UID/GID of user who called setup-shr-chroot. Then you need root to be able to bind important system directories to it and then change / to it.

$ cd shr-chroot
$ sudo ./shr-chroot.sh

Now you don't need root anymore, so switch to prepared bitbake account and setup preferred shr version.

$ su - bitbake
$ make setup-shr-unstable # or setup-shr-testing/setup-shr-stable

This will checkout common directory with shared config files and Makefile, openembedded directory with OE and shr-unstable directory. You need to do this step even if you have old shr-unstable builddir to get new config files!

To build first image:

cd shr-unstable
. ./setup-env

bb -k shr-image

Building SHR for other devices

MACHINE=om-gta01 bb -k shr-image #will build it for om-gta01 instead of default om-gta02, or you can change it in setup-local (and ". ./setup-env" again).

Be aware that for proper multimachine builds you need to remove cache after changing MACHINE.

rm -f tmp/cache/bb_cache.dat

This step won't be needed after http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-February/030431.html is applied and I'll be able to revert this: http://git.shr-project.org/git/?p=shr-makefile.git;a=commit;h=3e81fa62ada5e938acb20fe970af9ae56196e6a9

Migrate old data/builds to shr-chroot environment

Reuse old checkout/downloads if you have them already on disk:

cp -ra ../openembedded shr-chroot/OE
cp -ra ../downloads shr-chroot/OE

You can migrate old builddir (in case you don't want to rebuild from scratch), but I strongly recommend to rebuild from scratch if your tmpdir wasn't in path /OE/shr-unstable/tmp before. For rebuild from scratch you could still migrate old cache directory to have upgradeable path.

exit; #to chrooted root
exit; #to root in normal /
exit; #to normal user
cd .. #to directory above shr-chroot

cp -ra ../shr-unstable/tmp shr-chroot/OE/shr-unstable/tmp
# migrate to per-machine cache (LOCALCOUNT numbers etc), this step is needed if you want to preserve upgradeable path from old image.
echo "/OE/shr-unstable/tmp" >> shr-chroot/OE/shr-unstable/tmp/saved_tmpdir # update saved_tmpdir if needed to new location, very tricky, stuff can fall apart, better to rebuild from scratch

su
./shr-chroot.sh

Recreate config files

Configuration files ie in shr-unstable/conf are not updated after initial setup-shr-unstable. If you want to refresh them with current version.

mv shr-unstable/conf shr-unstable/conf-old
rm -f shr-unstable/.configured
make setup-shr-unstable
# check diff
diff -rq shr-unstable/conf-old shr-unstable/conf

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

Set up your local.conf

local.conf can be found at shr-unstable/conf/local.conf or shr-testing/conf/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):

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
$ bitbake -k shr-image

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

$ cd shr-unstable
$ MACHINE=om-gta01 bitbake -k shr-image
$ # or update setup-local

Building an image

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

$ cd shr-unstable
$ bitbake -k shr-image or bitbake -k shr-lite-image

When 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/.

Building the all packges

If you want to build everything that is available in the shr feeds run the following:

bitbake -k task-shr-feed

The -k allows the build to continue if an individual package fails. (ref: http://bitbake.berlios.de/manual/ch04s02.html )

Making changes

TODO: fix better

The below mentioned shr-dialer is now part of phoneui-apps, so you can run

bitbake phoneui-apps

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

Update sample in shr-unstable/conf/local-builds.inc to point to right directory:

S_pn-libphone-ui-shr = "/path/to/source/${PN}" # update this!

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 compile and package build (but clean is needed when updating patches applied in SRC_URI), 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 --rebase

Be aware that "make update*" will always revert your local changes to repo. If you want to keep them, then better to call "git pull --rebase" manually.

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.

Please set the 'CACHE' variable

If you get the error 'Please set the 'CACHE' variable', then you've probably forgot to run ". ./setup-env" in your current shell.

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 gcc-cross-initial gcc-cross-intermediate gcc-cross gcc gcc-cross-sdk binutils-cross binutils binutils-cross-sdk eglibc-initial eglibc && bitbake eglibc

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.

libgee: do_configure fails

since 2010-10-17 06:52:41 libgee configure will NOT use its own libtool macros. So it needs a native libtool installed on your build host.

install libtool (eg: Ubuntu /Debian):

dpkg install libtool

and then build again

. ./setup-env
bitbake -c clean libgee
make image

rebuilding from scratch

to completely rebuild everything from scratch, remove everything except cache/ from shr-unstable/tmp/

cd shr-unstable/tmp/
ls | grep -v cache | xargs rm -rf

ffmpeg

apply this patch from Martin Jansa before you build () ref: http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-March/030534.html ref: http://patches.openembedded.org/patch/935/

cd shr-unstable/openembedded
contrib/patchwork/pw-am.sh 935

Obsolete Troubleshouting

eve

Obsolete as this patch is included in official OE repository

apply this patch from Martin Jansa before you build ref: http://lists.shr-project.org/pipermail/shr-devel/2011-February/003580.html ref: http://patchwork.dev.bearstech.com/patch/856/

cd shr-unstable/openembedded; 
~/bin/pw-am.sh 856 # if you have shr-chroot, or 
wget http://patchwork.dev.bearstech.com/patch/856/mbox/ -O 856.patch; 
git am -s 856.patch;

/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)