Next Previous Contents

2. Installation

This chapter describes the installs that need to be done, if openembedded should be used for development.

2.1 Required Software

The following list is a possibly not full list of required software for OE development. Even the list may change in the future.

Hint : The versions provided in the list below are version as installed on my host at time of OE installation. Older version may work as well.

On Debian systems you can easily install the packages.

For latest information and other OS look here.

2.2 Preparations

The OE system is designed to run on different platforms, so some assumptions have to me made to guarantee that. To be able to find the compiler tools, you have to set links to your gcc and other components (/usr/bin on a debian system).

Install bitbake

This section explains, how to install bitbake, the central development tool of OE on your machine. Follow the steps described below.

See FAQ, if bitbake does not setup.

See FAQ, if bitbake does not work after a python package update.

Update bitbake (from 1.3.2.x to 1.3.3.x)

This section explains, how to update bitbake, the central development tool of OE on your machine. Note that you should not have an older bitbake version installed from a different target or installed into a different target. This may cause problems in loading the correct python modules.

Follow the steps described below.

If you want ot build a new OE package, you have to update to the newest OE repository. The best is to create a new repository as well as a new environment and build dir to really start from scratch and to avoid destroying your probably working setup. Up to now I had no problems to use the new bitbake version with the old repository. So it seems to be possible to have a stable tree and a develop version (with new Repository).

See FAQ, if bitbake does not setup.

See FAQ, if bitbake does not work after a python package update.

Update bitbake (from 1.3.3.x to 1.4.1)

This section explains, how to update bitbake, the central development tool of OE on your machine. Note that you should not have an older bitbake version installed from a different target or installed into a different target. This may cause problems in loading the correct python modules.

Follow the steps described below.

NOTE, that if you use bitbake 1.5.x, you did not catch the stable version. 1.5.0 e.g. has problems finding patches (for the openzaurus kernel e.g.)

Download OE packages with monotone

To get an initial packages repository, follow the steps below.

To have things not spread arround, you may want to create a directory (e.g. "oe"). CD into that dir and run the following commands.

  1. First time monotone usage requires two steps to get ready.
    Note that you can skip item 1, if already done.
  2. Init monotones database.
    monotone --db=OE.db db init
  3. Pull initial database example (from vanille.de)
    Note that you can skip item 2, if already done.
    monotone --db=OE.db pull monotone.vanille.de org.openembedded NOTE, that this may take more than a day (for some reasons)
  4. To checkout your repository do a
    monotone --db=OE.db co --branch=org.openembedded.dev
  5. To update your existing repository change to your monotones db dir and do a
    monotone --db=OE.db pull;cd org.openembedded.dev;monotone --db=../OE.db update NOTE, that the pull may take more than a day (for some reasons).

More information can be found at
the monotone OE wiki and
the monotone homepage.

You may want to try the following servers instead of monotone.vanille.de

Note that an initial pull can take very long
(hours, if not days) - we strongly recommend basing your database off our daily snapshots http://ewi546.ewi.utwente.nl/OE/

Download a snapshot and unpack that in your OE develop dir followed by a checkout and a final pull. That bring the newest stuff in.

Note that since jan2006 heavy changes are going to be made to the toolchain
thus you may want to update the "stable" tree only. You can do that by adding -rjan2006prebreakage to you checkout or update command.

Create a matching environment script

You may want to create one or more different environment scripts to be able to build e.g. for different platforms. The following paragraph shows an example for my CL860 build target.

# sample oe-env script - 'source oe-env' to use this environment.
#
# NOTE:
# In this example, I have a dir in my home directory called 'src/', where I
# do all my development work.  In this dir I
# have downloaded the 'oe/' and 'packages/' tree from the BitKeeper
# repository, and I have manually "mkdir'ed" the oe_downloads/ dir.
#
# The setup looks like this:
#       /home/user/src/oe/                    <- main OE dev
#       /home/user/src/oe/                 <- oe/ system bk tree
#       /home/user/src/oe/packages/           <- packages/ bk tree
#       /home/user/src/build/              <- where *ALL* builds occur
#       /home/user/src/oe_downloads/       <- oe dl's stuff here
#
# CHANGE 'user' to whatever your username is!  Also, be sure to carefully
# check the DL_DIR value in your $OEBUILD/conf/local.conf file ...
#
# - where is the OE system dir?
OESYS=/home/sc/scdev/oe
OESYS2=/data/scdev2

# - where does openembedded live?  i.e. where did you 'bk pull oe' and 'bk pull packages'?
OEROOT=$OESYS/org.openembedded.dev

# - where do all the packages live?
PKGDIR=$OEROOT/packages

# - where will *ALL* builds be occurring?
OEBUILD=$OESYS2/build-boxer-mono

# - the path OE will search in order to find "$OEPATH/conf/*.conf" files.  Yes, thats what this path is for.
OEPATH=$OEBUILD:$PKGDIR:$OESYS
#       [NOTE:  OE's *.conf files are -all- supposed to be in a dir named 'conf/' within these dirs ...
#               OE prepends 'conf' itself when looking for these files, so we don't do it ... strange but true ...]

# - add the oe/bin dir to this shells' path - without this, you get no 'oemake' or 'oebuild' or 'oecommander'...
# PATH=/usr/local/arm/2.95.3/bin:$OESYS/bin/:$PATH
# PATH=$OESYS/bin/:$PATH
PATH=$OESYS/scscripts:$PATH
# NOTE: this assumes you have the arm 2.95.3 tools installed as per the instructions on
# http://www.openembedded.org/oe_wiki/index.php/ZaurusKernels

# change to the build dir
cd $OEBUILD

# Blank this so we don't link non-arm libraries
LD_LIBRARY_PATH=
CC=
CXX=

BBPATH=$OEBUILD:$OEROOT
# Don't export TARGET_ARCH - it *will* cause build failures
export PATH LD_LIBRARY_PATH OEPATH CC CXX BBPATH

# Stop multi byte characters breaking the patcher stuff - This is for Redhat / Fedora people really
export LANG=C

echo Environment set up for OpenEmbedded development.
PS1="[OE-BOXER-mono]$PS1"

The script can be called with a simple . env-boxer-mono,sets some environment variables and changes into the defined build dir.

Prepare OE system

Create a build dir for your target machine named e.g. build-boxer. Enter that directory and create a dir called conf. Copy ../openembedded/conf/local.conf.sample to conf/local.conf and edit that file.

Note, that you have explicitely to provide a different BBFILES entry, as the sample entry creates an "fatal" error message. As well you have to delete the last line.

        # REMOVE_THIS_LINE:="${@oe.fatal('Read the comments in your conf/local.conf')}"

The following list tries to explain the meaning of the different entries of that file. Every item discussed is an example of my local.conf used for boxer (CL860) development (should also work for SL5500).

The rest of the file can be left as is (except the last line, which has to be commented out). From now on, we can start to build.

Install crosscompiler

A bitbake gcc-cross will do that for you. The cross-compiler will be installed in tmp/staging in your build environment.

Note, that this will be done automatically during an image-build.

Install openzaurus kernel crosscompiler

To be able to compile kernels for the Zaurus modells, the system has to use the sharp 2.95.3 cross toolkit. This section describes the installation of that toolkit and the necessary modifications for OE. Follow the hints below.

  1. Be sure the loadkeys binary is installed on your system. (Debian users can find it in the console-tools or kbd packages).
    A loadkeys -V prints out a version message (if loadkeys is installed on your system).

    Note, that onj Debian systems you may have to chmod your /dev/console file to 664 to allow a kernel build loadkeys call for a non superuser.
  2. Download GCC 2.95.3 toolchain - it is available here (possibly).
  3. Unpack it into /usr/local/arm/ - Do not try to install it elsewhere or hardcoded absolute references to bits and pieces will fail, like cpp0 and cc1 being reported missing about 1-2 hours after starting a build...
  4. cd /usr/local/arm/2.95.3/bin
  5. mv arm-linux-gcc arm-linux-gcc-2.95
  6. mv arm-linux-ld arm-linux-ld-2.11.2
  7. add ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95" into oe/build/conf/local.conf
  8. add /usr/local/arm/2.95.3/bin into your PATH variable.

Note :, that you really have to move the binaries. A link will not work for some strange reason.

2006 : Note! I heared, that the above mentioned moves do avoid building a target with this compiler in bitbake 1.3.3.x environment. Though am not willing to test that I would try to do a run without the moves.

2.3 Working behind a proxy

Working behind a firewall (proxy) brings up some problems.

Http and ftp

As http and ftp downloads are done using wget it is straight forward to use a proxy. You either have to insert lines like 

         http_proxy="http://proxy.server.this.that:port_no/"
         ftp_proxy="ftp://proxy.server.this.that:port_no/"
         export http_proxy ftp_proxy
into your environment script or insert that entries into  /.wgetrc.
You just have to care to get wget working with your proxy.

Note, that the pending "/" is possibly important to get wget working.

Cvs

You can either ask your system administrator to open port 2401 (and 22 for ssh access) ;-) or setup a ssh proxy going via 443 (https) port. This method is described in the below paragraph.

This paragraph just shows the irc communication regarding that item. Until I do not have the stuff working, this is all I have.

        MP0 wrote:
        used transconnect to ssh through the http proxy to an outside machine
        used danteserver on the outside machine to have a socks4 proxy
        then used proxychains on the development machine to use the socks4 proxy on my outside machine through an ssh tunnel
        
        I think (not sure) that oe respects my http_proxy environment variable. unfortunately, it didn't use it for ftp
        you could also try having http_proxy not set and using proxychains to connect out of your http proxy
        My personal solution was
        
        as for svn... my solution is to have a proxy on the outside
        I used transconnect to get an ssh tunnel to the machine on the outside
        it's rather slow, but other than changing the structure of IT, what can I do.

        either set up your proxy to work on port 443
        and use proxytunnel to go through both your corporate proxy and your outside proxy
        or
        (what I did, since it was already semi-set up)
        I had my outside machine running ssh on port 443 (always handy to have)
        ie, I put "port 443" in /etc/sshd/blahblahblah
        whatever the config file is called
        and restarted sshd
        since sshd is running on port 443, I can create a tunnel
        now, ssh has a neat feature
        the -D option
        it acts like a socks4/socks5 server
        so
        using transconnect or proxychains

        proxychains ssh -D 8080 MP0@someserver
        the only problem I have with that approach is
        (ie, using ssh)
        is I need to use a seperate program to get the ssh connection through the corporate proxy
        and one to get oe to use my ssh proxy
        that's why I use both proxychains and transconnect... one of them is configured to get ssh out of the
        corprorate proxy, the other is configured to make programs use my ssh proxy
        if you have your outside proxy server proxying on port 443 already (instead of ssh on 443),
        then you can use proxychains alone without another program.
        
        cuz proxychains, as its name implies, allows you to chain proxies... get through the
        corprorate proxy, and get through your outside proxy

Alternatively, OE could use the fetch.patch by jordan crouse (amd), which as announced in the bitbake and oe mailing list. This patch enables cvs 1.10+ to use http_proxy directly unsing http_proxy environment settings. I am not sure, whether this patch is in already.

More ionfo can be found here.

Subversion

Until now I never saw a package not downloading using either http, ftp or cvs. Subversion is also possible, but not used for repository.

If you have to update bitbake itself, your sysadmin has to open port 3690 (svn).

Instead of that, you may want to just copy your home bitbake version to you office ;-)

Monotone

If you have to update or create your OE repository, your sysadmin has to open port 5253 (monotone).

Instead of that, you may want to just copy your home oe.db and org.openembedded.dev dir.

Next Previous Contents