Openembedded.org - User contributions [en]

Commit Patch Message Guidelines

2017-11-13T14:23:02Z

Mwelchuk: "Submitting Patches" documentation has moved. There's also an HTML version provided now.

This set of guidelines is intended to help both the developer and reviewers of
changes determine reasonable patch headers and change commit messages. Often
when working with the code, you forget that not everyone is as familiar with the
problem and/or fix as you are. Often the next person in the code doesn't
understand what or why something is done so they quickly look at patch header
and commit messages. Unless these messages are clear it will be difficult to
understand the relevance of a given change and how future changes may impact
previous decisions.

This policy refers both to patches that are being applied by recipes as well as
commit messages that are part of the source control system, usually git. A patch
file needs a header in order to describe the specific changes that are made
within that patch, while a commit message describes one or more changes to the
overall project or system. Both the patch headers and commit messages require
the same attention and basic details, however the purposes of the messages are
slightly different. A commit message documents all of the changes made as part
of a commit, while a patch header documents items specific to a single patch. In
many cases the patch header can also be used as the commit message.

This policy does not cover the testing of the changes, the technical criteria
for accepting a patch, nor the style requirements for the technical changes. See
the [http://www.openembedded.org/wiki/Styleguide Styleguide] for more information on style requirements.

By following these guidelines we will have a better record of the problems and
solutions made over the course of development. It will also help establish a
clear provenance of all of the code and changes.

Draft version, changes from last approved version:
* Revised General Information section to correct broken link
* Clarify the ''Developer's Certificate of Origin''

== General Information ==

While specific to the Linux kernel development, the following could also be
considered a general guide for any Open Source development:

https://www.linux.com/publications/how-participate-linux-community

Many of the guidelines in this document are related to the items referenced in
the link above.

Pay particular attention to section 5.3 that talks about patch preparation.
The key thing to remember is to break up your changes into logical sections.
Otherwise you run the risk of not being able to even explain the purpose of a
change in the patch headers!

In addition section 5.4 explains the purpose of the Signed-off-by: tag line. The
signed-off-by: tag line is the ''Developer's Certificate of Origin''. The full text
of which can be found in the Linux kernel's Documentation/SubmittingPatches.

Pay particular attention to section 11 of

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Due to the importance of the ''Developer's Certificate of Origin'', part of section 11
is copied below:

The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as an open-source patch. The rules are pretty simple: if you
can certify the below:

Developer's Certificate of Origin 1.1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

then you just add a line saying::

Signed-off-by: Random J Developer <random@developer.example.org>

using your real name (sorry, no pseudonyms or anonymous contributions.)

== Patch Headers and Commit Messages ==

There seems to always be a question or two surrounding what a person
should put in a patch header, or commit message.

The general rules always apply, those being that there is a single line
short log or summary of the change (think of this as the subject when the patch
is e-mailed), and then the more detailed long log, and closure with tag lines
such as "Signed-off-by:".

== New Development ==

A minimal patch or commit message would be of the format:

Short log / Statement of what needed to be changed.

(Optional pointers to external resources, such as defect tracking)

The intent of your change.

(Optional, if it's not clear from above) how your change resolves the
issues in the first part.

Tag line(s) at the end.

For example:

foobar: Adjusted the foo setting in bar

When using foobar on systems with less than a gigabyte of RAM common
usage patterns often result in an Out-of-memory condition causing
slowdowns and unexpected application termination.

Low-memory systems should continue to function without running into
memory-starvation conditions with minimal cost to systems with more
available memory. High-memory systems will be less able to use the
full extent of the system, a dynamically tunable option may be best,
long-term.

The foo setting in bar was decreased from X to X-50% in order to
ensure we don't exhaust all system memory with foobar threads.

Signed-off-by: Joe Developer <joe.developer@example.com>

The minimal commit message is good for new code development and simple changes.

The single short log message indicates what needed to be changed. It should
begin with an indicator as to the primary item changed by this work,
followed by a short summary of the change. In the above case we're indicating
that we've changed the "foobar" item, by "adjusting the foo setting in bar".

The single short log message is analogous to the git "commit summary". While no
maximum line length is specified by this policy, it is suggested that it remains
under 78 characters wherever possible.

Optionally, you may include pointers to defects this change corrects. Unless
the defect format is specified by the component you are modifying, it is
suggested that you use a full URL to specify the reference to the defect
information. Generally these pointers will precede any long description, but as
an optional item it may be after the long description.

For example, you might refer to an open source defect in the RPM project:

rpm: Adjusted the foo setting in bar

<nowiki>[RPM Ticket #65] -- http://rpm5.org/cvs/tktview?tn=65,5</nowiki>

The foo setting in bar was decreased from X to X-50% in order to
ensure we don't exhaust all system memory with foobar threads.

Signed-off-by: Joe Developer <joe.developer@example.com>

You must then have a full description of the change. Specifying the intent of
your change and if necessary how the change resolves the issue.

As mentioned above this is intended to answer the "what were you thinking"
questions down the road and to know what other impacts are likely to
result of the change needs to be reverted. It also allows for better
solutions if someone comes along later and agrees with paragraph 1
(the problem statement) and either disagrees with paragraph 2
(the design) or paragraph 3 (the implementation).

Finally one or more tag lines should exist. Each developer responsible
for working on the patch is responsible for adding a Signed-off-by: tag line.

It is not acceptable to have an empty or non-existent header, or just a single
line message. The summary and description is required for all changes.

== Importing from Elsewhere ==

If you are importing work from somewhere else, such as a cherry-pick from
another repository or a code patch pulled from a mailing list, the minimum patch
header or commit message is not enough. It does not clearly establish the
provenance of the code.

The following specifies the additional guidelines required for importing changes
from elsewhere.

By default you should keep the original author's summary and description,
along with any tag lines such as, "Signed-off-by:". If the original change that
was imported does not have a summary and/or commit message from the original
author, it is still your responsibility to add the summary and commit message to
the patch header. Just as if you wrote the code, you should be able to clearly
explain what the change does. It is also necessary to document the original
author of the change. You should indicate the original author by simply stating
"written by" or "posted to the ... mailing list by". You must not add a
Signed-off-by: tag line with their name, only the original author may add their
own Signed-off-by: tag line.

It is also required that the origin of the work be fully documented. The origin
should be specified as part of the commit message in a way that an average
developer would be able to track down the original code. URLs should reference
original authoritative sources and not mirrors.

If changes were required to resolve conflicts, they should be documented as
well. When incorporating a commit or patch from an external source, changes to
the functionality not related to resolving conflicts should be made in a
second commit or patch. This preserves the original external commit, and makes
the modifications clearly visible, and prevents confusion over the author of the
code.

Finally you must add a "Signed-off-by:" tag line to indicate that you worked
with the patch.

=== Example: Importing from Elsewhere Unmodified ===

For example, if you were to pull in the patch from the above example unmodified:

foobar: Adjusted the foo setting in bar

When using foobar on systems with less than a gigabyte of RAM common
usage patterns often result in an Out-of-memory condition causing
slowdowns and unexpected application termination.

Low-memory systems should continue to function without running into
memory-starvation conditions with minimal cost to systems with more
available memory. High-memory systems will be less able to use the
full extent of the system, a dynamically tunable option may be best,
long-term.

The foo setting in bar was decreased from X to X-50% in order to
ensure we don't exhaust all system memory with foobar threads.

Signed-off-by: Joe Developer <joe.developer@example.com>

The patch was imported from the OpenEmbedded git server
(<nowiki>git://git.openembedded.org/openembedded</nowiki>) as of commit id
b65a0e0c84cf489bfa00d6aa6c48abc5a237100f.

Signed-off-by: Your Name <your.name@openembedded.org>

The above example shows a clear way for a developer to find the original source
of the change. It indicates that the OpenEmbedded developer simply integrated
the change into the system without making any further modifications.

=== Example: Importing from Elsewhere Modified ===

When importing a patch, occasionally changes have to be made in order to resolve
conflicts. The following is an example of the commit message when the item needed
to be modified:

foobar: Adjusted the foo setting in bar

When using foobar on systems with less than a gigabyte of RAM common
usage patterns often result in an Out-of-memory condition causing
slowdowns and unexpected application termination.

Low-memory systems should continue to function without running into
memory-starvation conditions with minimal cost to systems with more
available memory. High-memory systems will be less able to use the
full extent of the system, a dynamically tunable option may be best,
long-term.

The foo setting in bar was decreased from X to X-50% in order to
ensure we don't exhaust all system memory with foobar threads.

Signed-off-by: Joe Developer <joe.developer@example.com>

The patch was imported from the OpenEmbedded git server
(<nowiki>git://git.openembedded.org/openembedded</nowiki>) as of commit id
b65a0e0c84cf489bfa00d6aa6c48abc5a237100f.

A previous change had modified the memory threshold calculation,
causing a conflict. The conflict was resolved by preserving the
memory threshold calculation from the existing implementation.

Signed-off-by: Your Name <your.name@openembedded.org>

== Patch Header Recommendations ==

In order to keep track of patches and ultimately reduce the number of patches
that are required to be maintained, we need to track the status of the patches
that are created. The following items are specific to patches applied by recipes.

In addition to the items mentioned above, we also want to track if it's
appropriate to get this particular patch into the upstream project. Since we
want to track this information, we need a consistent tag and status indicator
that can be searched.

While adding this tracking information to the patch headers is currently
optional, it is highly recommended and some maintainers may require it. It is
optional at this time so that it can be evaluated as to its usefulness over
time. Existing patches will be updated with the tag as they are modified.

As mentioned in the above, be sure to include any URL to bug tracking, mailing
lists or other reference material pertaining to the patch. Then add a new tag
"Upstream-Status:" which contains one of the following items:

'''Pending'''
- No determination has been made yet or not yet submitted to upstream

'''Submitted''' [where]
- Submitted to upstream, waiting approval
- Optionally include where it was submitted, such as the author, mailing
list, etc.

'''Accepted'''
- Accepted in upstream, expect it to be removed at next update, include
expected version info

'''Backport'''
- Backported from new upstream version, because we are at a fixed version,
include upstream version info

'''Denied'''
- Not accepted by upstream, include reason in patch

'''Inappropriate [reason]'''
- The patch is not appropriate for upstream, include a brief reason on the
same line enclosed with []
reason can be:
not author (You are not the author and do not intend to upstream this,
source must be listed in the comments)
native
licensing
configuration
enable feature
disable feature
bugfix (add bug URL here)
embedded specific
no upstream (the upstream is no longer available -- dead project)
other (give details in comments)

The various "Inappropriate [reason]" status items are meant to indicate that the
person responsible for adding this patch to the system does not intend to
upstream the patch for a specific reason. Unless otherwise noted, another
person could submit this patch to the upstream, if they do the status should be
changed to "Submitted [where]", and an additional Signed-off-by: line added to
the patch by the person claiming responsibility for upstreaming.

For example, if the patch has been submitted upstream:

rpm: Adjusted the foo setting in bar

<nowiki>[RPM Ticket #65] -- http://rpm5.org/cvs/tktview?tn=65,5</nowiki>

The foo setting in bar was decreased from X to X-50% in order to
ensure we don't exhaust all system memory with foobar threads.

Upstream-Status: Submitted [rpm5-devel@rpm5.org]

Signed-off-by: Joe Developer <joe.developer@example.com>

A future commit can change the value to "Accepted" or "Denied" as appropriate.

=== CVE Patches ===

In order to have a better control of vulnerabilities, patches that fix CVEs must contain the "CVE:" tag. This tag list all CVEs fixed by the patch. If more than one CVE is fixed, separate them using spaces.

==== Example: CVE patch header ====

This should be the header of patch that fixes grub2 CVE-2015-8370:

grub2: Fix CVE-2015-8370

<nowiki>[No upstream tracking] -- https://bugzilla.redhat.com/show_bug.cgi?id=1286966</nowiki>

Back to 28; Grub2 Authentication

Two functions suffer from integer underflow fault; the grub_username_get() and grub_password_get()located in
grub-core/normal/auth.c and lib/crypto.c respectively. This can be exploited to obtain a Grub rescue shell.

<nowiki>Upstream-Status: Accepted [http://git.savannah.gnu.org/cgit/grub.git/commit/?id=451d80e52d851432e109771bb8febafca7a5f1f2]</nowiki>
CVE: CVE-2015-8370
Signed-off-by: Joe Developer <joe.developer@example.com>

== Common Errors in Patch and Commit Messages ==

- Short log does not start with the file or component being modified. Such as
"foo: Update to new upstream version 5.8.9"

- Avoid starting the summary line with a capital letter, unless the component
being referred to also begins with a capital letter.

- Don't have one huge patch, split your change into logical subparts. It's
easier to track down problems afterward using tools such as git bisect. It also
makes it easy for people to cherry-pick changes into things like stable branches.

- Don't simply translate your change into English for a commit log. The log
"Change compare from zero to one" is bad because it describes only the code
change in the patch; we can see that from reading the patch itself. Let the code
tell the story of the mechanics of the change (as much as possible), and let
your comment tell the other details -- i.e. what the problem was, how it
manifested itself (symptoms), and if necessary, the justification for why the
fix was done in manner that it was. In other words, the long commit message
must describe *why* the change was needed (instead of what has changed).

- Don't start your commit log with "This patch..." -- we already know it is a patch.

- Don't repeat your short log in the long log. If you really really don't have
anything new and informational to add in as a long log, then don't put a long
log at all. This should be uncommon -- i.e. the only acceptable cases for no
long log would be something like "Documentation/README: Fix spelling mistakes".

- Don't put absolute paths to source files that are specific to your site, i.e.
if you get a compile error on "fs/exec.c" then tidy up the parts of the compile
output to just show that portion. We don't need to see that it was
/home/wally/src/git/oe-core/meta/classes/insane.bbclass or similar - that full
path has no value to others. Always reduce the path to something more
meaningful, such as oe-core/meta/classes/insane.bbclass.

- Always use the most significant ramification of the change in the words of
your subject/shortlog. For example, don't say "fix compile warning in foo" when
the compiler warning was really telling us that we were dereferencing complete
garbage off in the weeds that could in theory cause an OOPS under some
circumstances. When people are choosing commits for backports to stable or
distro kernels, the shortlog will be what they use for an initial sorting
selection. If they see "Fix possible OOPS in...." then these people will look
closer, whereas they most likely will skip over simple warning fixes.

- Don't put in the full 20 or more lines of a backtrace when really it is just
the last 5 or so function calls that are relevant to the crash/fix. If the entry
point, or start of the trace is relevant (i.e. a syscall or similar), you can
leave that, and then replace a chunk of the intermediate calls in the middle
with a single [...]

- Don't include timestamps or other unnecessary information, unless they are
relevant to the situation (i.e. indicating an unacceptable delay in a driver
initialization etc.)

- Don't use links to temporary resources like pastebin and friends. The commit
message may be read long after this resource timed out.

- Don't reference mirrors, but instead always reference original authoritative
sources.

- Avoid punctuation in the short log.

[[Category:Policy]]

Adding a new Machine

2010-03-10T14:36:36Z

Mwelchuk:

== Kernel configuration ==

# Find out which kernel version your custom kernel is (e.g. 2.6.27)
# Extract the diff: <tt>diff -Nurd linux-2.6.27/ linux-2.6.27-mymachine/</tt> (this step is optional if you already have a diff)
# Add <tt>DEFAULT_PREFERENCE_mymachine = "1"</tt> and <tt>SRC_URI_append_mymachine = "file://mymachine.diff"</tt> to <tt>linux_2.6.27.bb</tt>
# Put <tt>defconfig</tt> in <tt>recipes/linux/linux-2.6.27/mymachine/defconfig</tt>

If you really, really need to be ''special'' (which you really don't need, but companies seem to feel better when their name is plastered all over the place e.g. <tt>linux-mycompany_2.6.27.bb</tt>) you can create your ''own'' kernel recipe with the naming options you mentioned, then please use <tt>linux.inc</tt> to the basics working well. If even that is not ''special'' enough, then well, you are on your own.

By reusing a <tt>linux_2.6.xx</tt> recipe you can easily see what kind of patches other machines are applying and how issues with that kernel get solved.

== General steps and traps ==

Most of the time people that add new hardware to OE go through something like this (ARM example):

# Add <tt>mymachine.conf</tt>, <tt>linux-mymachine_2.6.xx.bb</tt>, <tt>openmymachine.conf</tt> distro
# Complain toolchain doesn't build, copy over versions from angstrom to get it fixed
# Complain their device doesn't boot, change defconfig to support EABI to get it fixed
# Complain NFS doesn't work, change defconfig to get that fixed

The toolchain problems wouldn't have been there if people had used an existing, working distro like angstrom, the kernel issues mentioned above are all handled automagically by linux.inc.

So people, please start by reusing existing things and creating your own stuff '''when need arises''', not when NIH arises.

== Further comments and information ==

* [http://docs.openembedded.org/usermanual/usermanual.html#commonuse_new_machine Adding a new Machine], Chapter 5. Common Use-cases/tasks, OpenEmbedded User Manual
* where available, don't forget to provide an URL to the machine's homepage in the machine configs for those who want to know more about it.

[[Category:Dev]]
[[Category:Machine]]

Documentation

2010-01-01T13:11:44Z

Mwelchuk: Undo revision 2008 by 194.8.75.155 (Talk)

Documentation that relates to Openembedded.

* [http://docs.openembedded.org/usermanual/html OE User manual] [http://docs.openembedded.org/usermanual/usermanual.pdf (pdf)] [http://docs.openembedded.org/usermanual/usermanual.html (html single-page)]
* [http://docs.openembedded.org/bitbake/html/ Bitbake Manual]
* [http://www.pokylinux.org/doc/poky-handbook.html Poky Handbook]

Articles about Openembedded:
* [http://bec-systems.com/site/tag/openembedded articles at BEC Systems]
** [http://bec-systems.com/site/456/capture-oe-source-changes How to Capture OE Source Code Changes to a Package]

Guides and HowTos:
* [http://www.kernel-labs.org/files/openembedded-guide/openembedded-guide.html OpenEmbedded Guide by Example]
* [http://www.uv-ac.de/openembedded/ OpenEmbedded HowTo]
* [http://free-electrons.com/docs/openembedded/ Using OpenEmbedded to build embedded Linux distributions]

[[Category:User]]
[[Category:Dev]]

Required software

2009-11-05T09:59:14Z

Mwelchuk: Ccache is no longer recommended for use when using OpenEmbedded

= OpenEmbedded's Software Requirements =

This page is the reference of what software is needed. But [[OEandYourDistro]] is likely much faster in getting you that software actually installed.

To use the OE build system the following software is required on your system:
* [http://www.python.org/ Python] (Version 2.4.0 or later)
** Note that you may also need certain development files for Python e.g. for bitbake's setup.py to work. Depending on the distribution you use you may want to look for a package called "python-dev", "python-devel", or similar.
* [http://www.gnu.org/software/patch/patch.html GNU Patch] (Version 2.5.9 or later, see ftp://alpha.gnu.org/gnu/diffutils/ . It is a "testing release" and is not mirrored on the GNU mirrors.)
* [http://www.gnu.org/software/m4/m4.html GNU m4]
* [http://www.gnu.org/software/make/ GNU make] (Version 3.80 or later for hh.org kernels)
* [http://psyco.sourceforge.net/ Psyco JIT Compiler] is recommended to increase performance (32bit only)
* [http://www.perl.org/ perl] (needs newer than 5.0, how much newer? probably at least 5.6.2)
* [http://invisible-island.net/diffstat/diffstat.html diffstat]
* [http://developer.berlios.de/projects/bitbake bitbake]

== Tools to download source files ==
* wget
* curl
* ftp
* [http://www.nongnu.org/cvs/ cvs]
* [http://subversion.tigris.org/ subversion]
* [http://git.or.cz/index.html git]

== Tools to verify integrity of the downloaded sources ==
* md5sum
* sha256sum

== Tools to unpack sources ==
* tar
* bzip2
* gzip
* unzip

== Tools to build the various *-doc packages==
* [http://www.jclark.com/jade/ Jade] or [http://www.netfolder.com/DSSSL/ OpenJade]
** I don't know which of these is preferred
* [http://sourceforge.net/projects/docbook/ Docbook] DTDs and DSSSL stylesheets
* [http://sgmltools-lite.sourceforge.net/ sgmltools], called "sgmltools-lite" too
* [http://sources.redhat.com/docbook-tools/ docbook-utils]
** docbook-utils download is hard to find; look in ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES
* [ftp://ftp.gnu.org/pub/gnu/texinfo/ Texinfo]
* [http://www.nongnu.org/texi2html/ texi2html] (Perl script that converts Texinfo to HTML)

== Other packages ==
* [http://www.gnu.org/software/sed/sed.html GNU sed] 4.x
* [http://www.gnu.org/software/bison/bison.html Bison]
* bc (binary calculator), if you want to build a Zaurus 2.4 or any of the collie kernels
* glibc headers (libc6-dev in Debian, glibc-devel in RPM based (in PLD also glibc-static is needed))
* [http://www.pcre.org/ pcre headers] (Perl 5 Compatible Regular Expression Library, required for e.g. konqueror-embedded)
* SDL headers to build qemu-native (apt-get install libsdl1.2-dev under Ubuntu/Debian)
* [http://www.mktemp.org/mktemp/ mktemp] (required by quilt and used in some package patches)
* help2man - Create simple man pages from --help output

There is an ongoing effort to accurately document the required software within the OpenEmbedded and ultimately, this will be reflected in the ASSUME_PROVIDED variable.

[[Category:User]]

Getting started with OE-Classic

2009-11-05T09:58:30Z

Mwelchuk: We no longer suggest using ccache as it has been fingered for breaking builds

= Setting up the toolchain and doing a build =

== Directory Structure ==
The base directory of your Openembedded environment (<nowiki>/stuff/</nowiki>) is the location where sources will be checked out (or unpacked).

* You must choose a location with '''no symlinks above it'''

* If you work in a chrooted environment and have ccache installed it is highly recommended to 'su - <username>' after you have chrooted. Compilation may fail because ccache needs a valid <nowiki>$HOME</nowiki>, which is usually set when using a user account. It is recommended that ccache is not installed on systems used to build OpenEmbedded as it has been known to introduce other subtle build failures.

To create the directory structure:

<pre><nowiki>
$ mkdir -p /stuff/build/conf
$ cd /stuff/
</nowiki></pre>

== Obtaining BitBake ==
To start using OE, you must first obtain the build tool it needs: <nowiki>bitbake</nowiki>

It is recommended to run bitbake without installing it, as a sibling directory of <nowiki>openembedded/</nowiki> and <nowiki>build/</nowiki> directories. Indeed, as bitbake is written in python it does not need to be compiled. You'll just have to set the PATH variable so that the [[BitBake]] tools are accessible (see [[#Setup the environment|Setup the environment]] section).

===Using packages===

There is a BitBake package available for more and more distros - see [[OEandYourDistro]].

===Using releases===

Visit [http://developer.berlios.de/projects/bitbake/ BitBake homepage] and download tarball with latest release. For normal usage we suggest using 1.8.x (stable branch) versions. Unpack it to '''/stuff/bitbake/'''.

== Obtaining OpenEmbedded using GIT ==

''Note: ''Once upon a time OpenEmbedded was using Monotone for version control. If you have an OE Monotone repository on your computer, you should replace it with the Git repository.

''Note: ''These are only brief instructions. For a longer description about using Git with OpenEmbedded refer to [[Git]] and [[GitPhraseBook]].

The OpenEmbedded project resides in a Git repository. You can find it at ''git://git.openembedded.org/openembedded''.

Web interface is: http://cgit.openembedded.org/

To obtain Openembedded:
# Install git
# Go to the base directory of your OpenEmbedded environment
$ cd /stuff/
# Checkout the repository
$ git clone git://git.openembedded.org/openembedded

or for the firewall challenged try
$ git clone http://repo.or.cz/r/openembedded.git

This is the data you'll be using for all the work.

=== Updating OpenEmbedded ===
The .dev branch of OE is updated very frequently (as much as several times an hour). The distro branches are not updated as much but still fairly often. It seems good practice to update your OE tree at least daily. To do this, run
$ git pull
(note: this must be done in the directory created by the checkout of openembedded. On this page, this directory is <tt>/stuff/openembedded</tt>, but my checkout generated a directory <tt>/stuff/openembedded</tt>. Check the name of your subdir, and use the name on your machine in the following examples)

== Create local configuration ==
It's now time to create your local configuration.
While you could copy the default local.conf.sample like that:

<pre><nowiki>
$ cd /stuff/
$ cp openembedded/conf/local.conf.sample build/conf/local.conf
$ vi build/conf/local.conf
</nowiki></pre>

It is actually recommended to start smaller and keep local.conf.sample in the background and add entries from there step-by-step as you understand and need them. Please, do not just edit build/conf/local.conf.sample but actually READ it (read it and then edit).

For building a .dev branch, in your <nowiki>local.conf</nowiki> file, you should have at least the following three entries. Example for the Angstrom distribution and the Openmoko gta01 machine:
<pre><nowiki>
BBFILES = "/stuff/openembedded/recipes/*/*.bb"
DISTRO = "angstrom-2008.1"
MACHINE = "om-gta01"
</nowiki></pre>

If you choose to install OE in your home directory, modify local.conf to refer to the OE paths as /home/<username>/ rather than ~/. It does not find the *.bb packages otherwise.

== Setup the environment ==
One of the four command sets below will need to be run every time you open a terminal for development. (You can automate this in ~/.profile, /etc/profile, or perhaps use a script to set the necessary variables for using [[BitBake]].)

If you followed the recommendation above to use [[BitBake]] from svn:
<pre><nowiki>
$ export BBPATH=/stuff/build:/stuff/openembedded
$ export PATH=/stuff/bitbake/bin:$PATH
</nowiki></pre>

If you installed [[BitBake]]:
<pre><nowiki>
$ export BBPATH=/stuff/build:/stuff/openembedded
</nowiki></pre>

Alternative syntax for those using the tcsh shell (e.g FreeBSD):
<pre><nowiki>
$ setenv PATH "/stuff/bitbake/bin:"$PATH
$ setenv BBPATH "/stuff/build:/stuff/openembedded:"$BBPATH
</nowiki></pre>

== Start building ==
The primary interface to the build system is the <nowiki>bitbake</nowiki> command (see the bitbake users manual). <nowiki>bitbake</nowiki> will download and patch stuff from the network, so it helps if you are on a well connected machine.

Note that you should issue all bitbake commands from inside of the <nowiki>build/</nowiki> directory, or you should override TMPDIR to point elsewhere (by default it goes to <nowiki>tmp/</nowiki> relative to the directory you run the tools in).

Here are some example invocations:

Building a single package (e.g. nano):

<pre><nowiki>
$ bitbake nano
</nowiki></pre>

Building package sets (e.g. task-base):

<pre><nowiki>
$ bitbake task-base
</nowiki></pre>

''Special note for'' <nowiki>task-base</nowiki>: you may need additional setup for building this very one task. More details in [[ZaurusKernels]]

Building a group of packages and deploying them into a rootfs image:

GPE:

<pre><nowiki>
$ bitbake x11-gpe-image
</nowiki></pre>

X11:

<pre><nowiki>
$ bitbake x11-image
</nowiki></pre>

OPIE:

<pre><nowiki>
$ bitbake opie-image
</nowiki></pre>

('''NOTE:''' kergoth says it will take around 10GB of disk space to build an opie or gpe image for one architecture.<br>
sledge says: You can reduce it to ~4GB by [[Advanced_configuration|INHERIT += "rm_work"]])

('''NOTE:''' if you are using your custom kernel - set "Use the ARM EABI to compile the kernel (AEABI)" option in "Kernel Features")

See the /stuff/openembedded/recipes/meta/ directory if you're curious about what meta/task and image targets exist.

Building every package in the repository ('''NOTE:''' This will take a ''very'' long time and needs approx. 35 GB disk space):

<pre><nowiki>
$ bitbake world
</nowiki></pre>

Building a single package, bypassing the long parse step (and therefore its dependencies--use with care):

<pre><nowiki>
$ bitbake -b /stuff/openembedded/recipes/blah/blah.bb
</nowiki></pre>

See [[Useful targets]] for a description of some of the more useful meta-packages. You will typically need at least one of the base images (<nowiki>bootstrap-image</nowiki>, <nowiki>opie-image</nowiki> or <nowiki>gpe-image</nowiki>), and if and only if you're building for an [http://wiki.openzaurus.org/Main_Page OpenZaurus] target requiring an installer image (such as C3000), an additional <nowiki>pivotboot-image</nowiki>.

Output of the build process (temporary files, log files and the binaries) all ends up in the <nowiki>tmp</nowiki> directory. Most interesting is probably the <nowiki>tmp/work/</nowiki> directory. Just have a look around the [[DirectoryStructure]].

Images generated by building package groups like <nowiki>opie-image</nowiki> or <nowiki>pivotboot-image</nowiki> are placed in the <nowiki>tmp/deploy/images/</nowiki> directory. Individual ipkg packages are put in <nowiki>tmp/deploy/ipk</nowiki>.

== Adding Packages ==
# Create [[bbfile]].
# Try building it locally.
# Fix eventual problems.
# Send .[[bbfile]] or an [[OePatch]] to the [http://wiki.openembedded.net/index.php/Mailing_Lists openembedded-devel mailing list]. Please note that changes should comply with the [[Commit_Policy | commit policy]].

= Problems =
Try to solve problems first by checking that you have done everything right, that nothing has changed from this description and that you have the latest code (see [[GitPhraseBook]]). Look also in the log file (referenced in any error message you will receive). If you still have problems, try checking [[PossibleFailures]] and [http://www.openembedded.org/wiki/OeFaq#builderrors common build errors].
Above links are dead, you can try the [[:Category:FAQ]]. If problems persist, ask on [[IRC]] or in the [[Mailing lists|openembedded mailing list]].

The Openembedded metadata is changing constantly. This implies several things:

# Once you have a "known good" version that works well on your system, keep it! To update, clone a new copy; don't overwrite that working version until it's known to be safe.
# To resolve build problems, "git pull" is your good friend. Many times, the issues will already be fixed in the current tree.
# Not all metadata updates cause the local caches to update correctly. Sometimes you'll need to remove the ".../tmp" work directory and rebuild from scratch.
# Similar issues apply to the package sources you download.

= Portability issues =
Make sure to set <nowiki>TARGET_OS</nowiki> to something other than linux in local.conf if your host isn't linux.

GNU extensions to tools are often required. Symlink GNU patch, make, and cp (from fileutils), chmod, sed, find, tar, awk into your OE development path.

FreeBSD 4 users: Perl 5.0 is too old. A more recent perl must be available as <nowiki>/usr/bin/perl</nowiki>. Unfortunately just having more recent perl in the path isn't good enough. Some scripts are hard-coded for <nowiki>/usr/bin/perl</nowiki>. You can test for which perl you're using by typing perl -v. see /usr/ports/UPDATING for instructions on updating perl. Don't forget to do a use.perl port as instructed in /usr/ports/UPDATING

FreeBSD users: Set <nowiki>BUILD_OS</nowiki> in local.conf to freebsdN where N is your major version number. At least the cross gcc wants this.

FreeBSD users: The build process of glibc uses a very long command line at some places. Increase ARG_MAX to at least 131072, by editing /usr/sys/sys/syslimits.h and recompile your kernel (and reboot).

= Productivity notes =
Use the interactive bitbake mode ("bitbake -i") to speed up work when debugging or developing .bb files. Remember to run "parse" at the prompt first. Go!

If you want to save some compile time or are interested in additional tweaks to local.conf take a look at the [[Advanced configuration]] page.

[[Category:User]]

OEandYourDistro

2009-09-04T11:37:32Z

Mwelchuk: Removed any mention of ccache as it's fingered for breaking builds. Safely wrapped long commands.

See [[Required software]] for the list of the software required by Openembedded.

= Using OpenEmbedded on Linux systems =

== deb-based distributions ==

The easiest way is via [http://blog.leggewie.org/?p=39 apt-get'able Openembedded] which will pull the OE meta-data for you and keep it up-to-date. Plus, it makes sure all necessary software for cross-compilation is installed. Easy as 1-2-3.

=== Debian ===

==== Mandatory packages ====

apt-get install sed wget cvs subversion git-core \
coreutils unzip texi2html texinfo libsdl1.2-dev docbook-utils \
gawk python-pysqlite2 diffstat help2man make gcc build-essential g++

'''Git'''

On debian you may have to run

update-alternatives --config git (as root)

and select /usr/bin/git-scm to provide git instead of /usr/bin/git.transition. This is not necessary in sid

==== Supplimentary packages ====

<pre><nowiki>
apt-get install libxml2-utils xmlto python-psyco
</nowiki></pre>

OPTIONAL: these packages and their dependencies need to be installed in order to build the bitbake documentation (warning: over 160MB of installed packages).

<pre><nowiki>
apt-get install docbook
</nowiki></pre>
This package is necessary to build some packages (in particular the esound documentation needs it).

=== Ubuntu ===

Ubuntu is based on Debian and instructions above for [[#deb-based distributions|Debian]] apply here as well. Make sure that you have the universe repositories in your apt configuration.

* Check that /bin/sh (ls -l /bin/sh) is not symbolically linked to dash. "dash" is a POSIX compliant shell that is much smaller than "bash" -- however some broken shell scripts still make use of bash extensions while calling into /bin/sh. To work around this issue call "''sudo dpkg-reconfigure dash''" and select No when it asks you to install dash as /bin/sh.
* You can also install Psyco Python JIT compiler to speed up BitBake. Psyco works on 32-bit x86 platforms only. "''aptitude install python-psyco''
* there are known [[gcc issues in Intrepid and later]] when cross-compiling with OE

== rpm-based distributions ==

=== Mandriva Linux ===

Follow the Debian instructions, only using `urpmi` instead of `apt-get install`. You can find it in the contrib section of any Mandriva mirror or seach for it using the Mandriva Club rpm database [http://rpms.mandrakeclub.com]. You may need libpythonV.V-devel for bitbake setup instead of python-dev.
If you're building a 2.6 kernel, you also need the glibc-static-devel package.

with Mandriva Linux 2006, you need to issue the following command:

<pre><nowiki>
urpmi python python-devel python-psyco patch m4 sed bison make wget bzip2 \
cvs gawk glibc-devel gcc-c++ subversion sharutils coreutils docbook-utils openjade \
quilt pcre-devel unzip glibc-static-devel
</nowiki></pre>

=== openSUSE ===

==== openSUSE 11.1 ====

Use zypper to install the required packages:

zypper in subversion git python help2man diffstat wget gcc gcc-c++ libstdc++ glibc-devel texinfo automake

These packages may be useful as well: bison and [http://software.opensuse.org/search?baseproject=ALL&p=1&q=gcc33 gcc33] (for faster build using ASSUME_PROVIDED), gtk2-devel (in case your build will fail on missing gdk-pixbuf-csource), bc (for collie kernel), ncurses-devel (if you want to call kernel menuconfig). python psyco package is optional.

=== Fedora ===

==== Fedora Core 2/3 ====
Much of the following is probably already installed, but you can check with the following commands. You may want to use the yum.conf located at http://www.fedorafaq.org/. Note, this has not been tested yes as I am in the process of setting up a development environment.

<pre><nowiki> yum install python patch m4 sed make docbook* openjade glibc-devel xmlto</nowiki></pre>

* psyco: Download psyco-1.4-src.tar.gz (or later) and extract it. Go to the psycho top-level directory and run: `python setup.py install`.

* patch: FC3 default version should be enough. Optionally, install SuSe 9.1 package of it.

==== Fedora Core 4 ====
Almost all required packages for Openembedded are available in Fedora Core 4 and the Fedora Extras for Core 4. You can download them from <http://download.fedora.redhat.com/pub/fedora/linux/core> and <http://download.fedora.redhat.com/pub/fedora/linux/extras>. Check <http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4> for updates on the Core 4 packages.

Apart from the usual (native) development packages like gcc and binutils, you should check that you have the following RPM's installed:

* bison
* docbook* packages
* libpcre
* m4
* make
* openjade
* patch
* PyQt
* python
* python-psyco
* sed
* xmlto
* quilt (not required as OE builds it by itself, but install it if you want to use gquilt)

Use apt, synaptic, up2date or yum to automagically retrieve these packages or download and install them manually (lots of work).

==== Fedora Core 5/6 ====

Commands I used to install OE pre-requisites on FC5/6

This long command will ensure all pre-requisites are installed (patch is 2.5.4, not 2.5.9, but appears to work).

<pre><nowiki>
su -c "yum install python m4 make wget curl ftp cvs subversion tar bzip2 gzip \
unzip python-psyco perl texinfo texi2html diffstat openjade docbook-style-dsssl \
docbook-style-xsl docbook-dtds docbook-utils sed bison bc glibc-devel gcc binutils \
pcre pcre-devel git quilt groff linuxdoc-tools patch gcc gcc-c++ python-sqlite2 help2man"
</nowiki></pre>

or download the metapackage http://www.openembedded.org/dl/packages/rpm/openembedded-essential-1.1-1.noarch.rpm (may be out of date).

then do

<pre><nowiki>
su -c "yum localinstall openembedded-essential-1.1-1.noarch.rpm"
</nowiki></pre>

There are also rpm and src.rpm packages of bitbake 1.6.2 at http://www.openembedded.org/dl/packages/rpm/ pending a later version in Extras, currently 1.6.0.

Update - Current FC6 version is patch-2.5.4-29.2.2 as of this writing and works-for-me (see revision history for build instructions if current patch does not work for you).

I didn't install SGML tools. Please add if you know how

Update - Since about 2002 sgml-tools has apparently been replaced by linuxdoc-tools for FC.

==== Fedora 7 ====

This long command will ensure all pre-requisites are installed (patch is 2.5.4, not 2.5.9, but appears to work).

<pre><nowiki>
su -c "yum install python m4 make wget curl ftp cvs subversion tar bzip2 gzip unzip \
python-psyco perl texinfo texi2html diffstat openjade docbook-style-dsssl \
docbook-style-xsl docbook-dtds docbook-utils sed bison bc glibc-devel gcc binutils \
pcre pcre-devel git quilt groff linuxdoc-tools patch linuxdoc-tools gcc gcc-c++ \
help2man perl-ExtUtils-MakeMaker"
</nowiki></pre>

(if this is hard to copy from this HTML page, go to edit mode and copy from editor)

==== Fedora 11 ====

Fedora 11, compared to previous versions, brings the need to install "glibc-static" as well:

<pre><nowiki>
su -c "yum install python m4 make wget curl ftp cvs subversion tar bzip2 gzip unzip \
python-psyco perl texinfo texi2html diffstat openjade docbook-style-dsssl \
docbook-style-xsl docbook-dtds docbook-utils sed bison bc glibc-devel glibc-static \
gcc binutils pcre pcre-devel git quilt groff linuxdoc-tools patch linuxdoc-tools \
gcc gcc-c++ help2man perl-ExtUtils-MakeMaker"
</nowiki></pre>

(if this is hard to copy from this HTML page, go to edit mode and copy from editor)

=== CentOS 4.4 / Red Hat Enterprise Linux 4 ===
May also work for true EL4 or Scientific Linux - another RHEL rebuild

Even with several optional and 3rd party yum repos enabled (centosplus, kbsingh, RPMforge/Dag, Dries) a number of required packages are too old or unavailable for CentOS4. [It should be possible to use other package managers including apt/synaptic, up2date, and smart to get the required packages. The following assumes yum.]

I re-built the following SRPMS (with "$ rpmbuild --rebuild ..."):
* boost-1.33.1-10.fc5.src.rpm
* bitbake-1.6.2-1.src.rpm (Latest tarball from http://developer.berlios.de/projects/bitbake/ + modified spec from bitbake-1.6.0-2.fc7.src.rpm)

Might also want to try the rpm and src.rpm packages of bitbake 1.6.2 at http://www.openembedded.org/dl/packages/rpm/ - I have not.

Extra requirements for the builds included rpmdevtools, xmlto, and lynx.

I put packages in a local repo so I can do "yum install ...", otherwise can do "yum localinstall foo.1.2.3.noarch.rpm ...". It may be necessary to temporarily set "gpgcheck=0" in /etc/yum.conf to avoid complaints about unsigned packages.

For EL4 texi2html is available from the tetex package, currently tetex-2.0.2-22.EL4.7

Note that the the metapackage http://www.openembedded.org/dl/packages/rpm/openembedded-essential-1.1-1.noarch.rpm
should work except that it depends on texi2html.

Instead as root do

<pre><nowiki>
yum install bison coreutils cvs docbook-utils gawk git-core python quilt rpmlib \
sed subversion tetex texinfo unzip wget
</nowiki></pre>

I ended up with the following set of relevant packages after several iterations of building/updating to get "bitbake nano" to complete successfully:

* python-2.3.4-14.3
* m4-1.4.1-16
* make-3.80-6.EL4
* wget-1.10.2-0.40E
* curl-7.12.1-8.rhel4
* ftp-0.17-22
* cvs-1.11.17-9.RHEL4
* subversion-1.4.3-0.1.el4.rf
* tar-1.14-12.RHEL4
* bzip2-1.0.2-13.EL4.3
* gzip-1.3.3-16.rhel4
* unzip-5.51-7
* python-psyco-1.5-3.el4.kb
* perl-5.8.5-36.RHEL4
* texinfo-4.7-5.el4.2
* tetex-2.0.2-22.EL4.7
* diffstat-1.34-0_6.el4.at
* openjade-1.3.2-16_9.el4.at
* docbook-style-dsssl-1.78-4
* docbook-style-xsl-1.65.1-2
* docbook-dtds-1.0-25
* docbook-utils-0.6.14-4
* sed-4.1.2-5.EL4
* bison-1.875c-2
* bc-1.06-17.1
* glibc-devel-2.3.4-2.25
* gcc-3.4.6-3
* binutils-2.15.92.0.2-21
* pcre-4.5-3.2.RHEL4
* pcre-devel-4.5-3.2.RHEL4
* git-1.4.4.2-2.el4.kb
* bitbake-1.6.2-1

=== ALT Linux ===

You can read more about ALT Linux here: http://www.altlinux.com/en/

You can use synaptic or aptitude to install packages. Or use apt-get as shown below.

<pre><nowiki>
apt-get install git-core python python-dev python-module-psyco python-modules-sqlite3 \
patch m4 sed bison make wget bzip2 cvs gawk gcc-c++ subversion sharutils coreutils \
docbook-utils openjade quilt libpcre-devel unzip glibc-devel glibc-devel-static \
help2man texi2html perl-devel
</nowiki></pre>

For building bitbake manuals you have to install 'xmlto' package:

<pre><nowiki>
apt-get install xmlto
</nowiki></pre>

NOTES:
* This is tested on ALD 4.0/4.1/5.0.
* gcc-c++ is virtual package and can be provided by gcc4.3-c++ (ALD 5.0) and gcc4.1-c++ (ALD 4.0/4.1). Just select higher version.

=== Ark Linux 2008.1 ===
[http://www.arklinux.org/ Ark Linux] is a modern distribution well suited for Openembedded development. Footprint only 2.1G.

Required steps:

1) install required packages
<pre><nowiki>
apt-get install devel-core diffstat texi2html cvs subversion git texinfo psyco python-devel \
python-encodings python-sqlite help2man bitbake
</nowiki></pre>

2) upgrade
<pre><nowiki>
apt-get update
apt-get dist-upgrade

The following packages will be REPLACED:
texi2html (by texlive-texi2html)
The following NEW packages will be installed:
texlive-texi2html
</nowiki></pre>

3) finally create your OE tree (see [[Getting started]] instructions). bitbake is already included, so you can skip that step.

== other Linux distributions ==

=== Gentoo instructions ===
<pre><nowiki>
emerge -n \
psyco \
patch \
make \
sed \
dev-lang/python \
m4 \
bison \
cvs \
openjade \
quilt \
sgmltools-lite \
docbook-xml-dtd \
docbook-dsssl-stylesheets \
xmlto \
docbook-sgml-utils \
libpcre \
boost \
subversion \
texi2html \
pysqlite
</nowiki></pre>

Then follow the instructions in [[Getting started]] for obtaining bitbake and start the build.

=== Arch Linux (Duke) ===

Most of the packages are available in the repositories.

<pre><nowiki>
sudo pacman -S psyco patch make sed python m4 bison cvs quilt sgmltools-lite docbook-xml \
xmlto pcre boost jade git texinfo
</nowiki></pre>

In Arch Linux the install command is in /bin/install. Since most of Linux distribution assume that install is located in /usr/bin/install, you have to create a symlink:

<pre><nowiki>
sudo ln -s /bin/install /usr/bin/install
</nowiki></pre>

You can build BitBake by using this PKGBUILD:
<pre><nowiki>
pkgname=bitbake
pkgver=1.8.4
pkgrel=1
pkgdesc="A simple tool for task execution derived from Gentoo's portage"
url="http://developer.berlios.de/projects/bitbake/"
arch=('i686')
license=('GPL' 'custom')
depends=('python')
source=(http://download.berlios.de/bitbake/${pkgname}-${pkgver}.tar.gz)
md5sums=('508d9a61c635d469be8facc95151158b')

build() {
cd ${startdir}/src/${pkgname}-${pkgver}
python setup.py install --root=${startdir}/pkg

# Install vim extensions
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/contrib/vim/ftdetect/bitbake.vim \
${startdir}/pkg/usr/share/vim/ftplugin/bitbake.vim
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/contrib/vim/syntax/bitbake.vim \
${startdir}/pkg/usr/share/vim/syntax/bitbake.vim

# Handle MIT license
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/doc/COPYING.MIT \
${startdir}/pkg/usr/share/licenses/${pkgname}/COPYING.MIT
}
</nowiki></pre>

= Using OpenEmbedded on FreeBSD and other NON Linux Systems =

tbd

== FreeBSD ==

* Python == /usr/ports/lang/python
* GNU Patch == /usr/ports/devel/patch
* GNU m4 == /usr/ports/devel/m4
* GNU make == /usr/ports/devel/gmake
* wget == /usr/ports/ftp/wget
* Psyco JIT Compiler == /usr/ports/devel/py-psyco
* GNU sed == /usr/ports/textproc/gsed
* Bison == /usr/ports/devel/bison
* GCC 2.95.3 == /usr/ports/lang/gcc295
* bc == already in FreeBSD
* PyQt == /usr/ports/x11-toolkits/py-qt
* glibc headers (ignore)
* subversion == /usr/ports/devel/subversion
* git == /usr/ports/devel/git
* pcre == /usr/ports/devel/pcre

Ports has also has these: fileutils, jade, docbook, dsssl-docbook-modular, sgmltools

== Using OpenEmbedded on Mac OS X ==

By default OS X uses a filesystem that is '''not''' case sensitive. You need to ensure that at least your tmp directory is on a case sensitive filesystem or you may come across various packages that break, including the Linux kernel! These steps were carried out on a early 32 bit 10.5/Intel Mac - the install order matters for a couple of packages as does having them installed in a more normal location.

# Register at [https://connect.apple.com ADC] and download and install Xcode
# Compile and install [http://www.gnu.org/software/gettext/ GNU gettext]
# Using CPAN install Locale::gettext
# Compile and install [http://www.gnu.org/software/help2man/ help2man 1.29] - newer versions will not build without hacks
# Compile and install [http://www.gnu.org/software/wget/ wget], [http://www.gnu.org/software/gawk/ gawk], [http://www.gnu.org/software/coreutils/ coreutils] and [http://git-scm.com/ git] - wget appears to not work if you install it in /usr/local so use --prefix=/usr also note OS X provides a different version of mktemp which functions differently, be careful not to overwrite this as OS X might need it
# If you are on a 32 bit Mac you can of course install [http://psyco.sourceforge.net/ psyco]
# Fixup your PATH variable for your build user so that /usr/local/bin (or where ever coreutils etc is installed) comes before the OS X version in /usr/bin
# Install GNU sed 3.0.2, this will give you a version of sed that allows you to build sed 4.1.5 - you will need to overwrite the one provided by OS X with --prefix=/usr and ensure you are using 4.1.5 not 3.0.2 as 3.0.2 does not provide various options you need
# Install getopt from [http://software.frodo.looijaard.name/getopt/download.php here] - modify WITHOUT_GETTEXT=0 to WITHOUT_GETTEXT=1 in the Makefile and add -DWITHOUT_GETTEXT=$(WITHOUT_GETTEXT) to the line beginning with CPPFLAGS=

Now follow the Getting Started OpenEmbedded wiki guide. Unfortunately there are various issues building on OS X that will most likely prevent the toolchain from building.

Unfinished - tbd

= Using OpenEmbedded on Windows/Cygwin Systems =

Building Openembedded on Windows is currently unsupported, but [http://oe.linuxtogo.org/wiki/BuildOnCygwin work is in progress] to support buidling of meta-toolchain.bb on Windows/Cygwin hosts.

Getting started with OE-Classic

2009-03-04T14:25:38Z

Mwelchuk: /* Adding Packages */ Adding link to commit policy

= Introduction =

This page tells you how to get started with Openembedded, i.e. how to install OE and start building packages. Before you proceed, please look at the important bits of [[Required software]] that must be installed on your system.

'''IMPORTANT NOTES''': this guide assumes that:

* the base directory of your Openembedded environment is '''/stuff/'''
(As a normal user, you probably want to substitute this with /home/myuser/oe/stuff)
* you selected the '''org.openembedded.dev''' development branch

'''You do not have to be root''' to build packages or distributions with Openembedded. It is even recommended '''to always work as user, not as root'''.

<nowiki>org.openembedded.dev</nowiki> is a development branch, therefore your build will be based on the contents of this development branch which may not be what you intended. See [[DevelopmentBranches]] for other available branches including versioned branches. You might want to use the stable branch, which is called <nowiki>org.openembedded.stable</nowiki>.
One general-purpose distro is Angstrom, well maintained in both stable and development branches. More information about the Angstrom project can be found on [http://www.angstrom-distribution.org/ Angstrom homepage]

Again, for the rest of these notes, replace '''/stuff/''' with the base directory of your Openembedded environment and '''org.openembedded.dev''' with the name of the branch that you selected.

= Setting up the toolchain and doing a build =

== Directory Structure ==
The base directory of your Openembedded environment (<nowiki>/stuff/</nowiki>) is the location where sources will be checked out (or unpacked).

* You must choose a location with '''no symlinks above it'''

* If you work in a chrooted environment it is highly recommended to 'su - <username>' after you have chrooted. Otherwise compilation may fail because ccache needs a valid <nowiki>$HOME</nowiki> - which is set when using a user account.

To create the directory structure:

<pre><nowiki>
$ mkdir -p /stuff/build/conf
$ cd /stuff/
</nowiki></pre>

== Obtaining BitBake ==
To start using OE, you must first obtain the build tool it needs: <nowiki>bitbake</nowiki>

It is recommended to run bitbake without installing it, as a sibling directory of <nowiki>openembedded/</nowiki> and <nowiki>build/</nowiki> directories. Indeed, as bitbake is written in python it does not need compilation for being used. You'll just have to set the PATH variable so that the [[BitBake]] tools are accessible (see [[#Setup the environment|Setup the environment]] section).

===Using packages===

There is a BitBake package available for more and more distros - see [[OEandYourDistro]].

===Using releases===

Visit [http://developer.berlios.de/projects/bitbake/ BitBake homepage] and download tarball with latest release. For normal usage we suggest using 1.8.x (stable branch) versions. Unpack it to '''/stuff/bitbake/'''.

===Using Subversion===

Go to the base directory of your Openembedded environment and checkout bitbake:
<pre><nowiki>
$ cd /stuff/
$ svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake</nowiki></pre>
'''NOTE:''' for proxy handling, see [http://subversion.tigris.org/faq.html#proxy SVN FAQ]

==== Updating bitbake ====

Bitbake is being revised fairly often. Periodically it's a good idea to check the repository of [http://svn.berlios.de/viewcvs/bitbake/branches/ bitbake stable branches] to see if a new stable branch is available or if the current branch has been revised. Compare your existing bitbake directory with the latest bitbake branch in the repository. Your existing bitbake branch and its 'last changed revision' number can be found as follows:
<pre><nowiki>
$ cd /stuff/bitbake; svn info
</nowiki></pre>

If there is a new stable branch, you will want to move or delete your existing bitbake directory and repeat the process listed above under "To obtain bitbake". If there is no new branch, it is easy to update bitbake:
<pre><nowiki>
$ cd /stuff/bitbake; svn update
</nowiki></pre>

== Obtaining OpenEmbedded using GIT ==

''Note: ''Once upon a time OpenEmbedded was using Monotone for version control. If you have an OE Monotone repository on your computer, you should replace it with the Git repository.

''Note: ''These are only brief instructions. For a longer description about using Git with OpenEmbedded refer to [[Git]] and [[GitPhraseBook]].

The OpenEmbedded project resides in a Git repository. You can find it at ''git://git.openembedded.net/openembedded''

To obtain Openembedded:
# Install git
# Go to the base directory of your OpenEmbedded environment
$ cd /stuff/
# Checkout the repository
$ git clone git://git.openembedded.net/openembedded

or for the firewall challenged try
$ git clone http://repo.or.cz/r/openembedded.git

This is the data you'll be using for all the work.

=== Updating OpenEmbedded ===
The .dev branch of OE is updated very frequently (as much as several times an hour). The distro branches are not updated as much but still fairly often. It seems good practice to update your OE tree at least daily. To do this, run
$ git pull
(note: this must be done in the directory created by the checkout of openembedded. On this page, this directory is <tt>/stuff/openembedded</tt>, but my checkout generated a directory <tt>/stuff/openembedded</tt>. Check the name of your subdir, and use the name on your machine in the following examples)

== Create local configuration ==
It's now time to create your local configuration.
While you could copy the default local.conf.sample like that:

<pre><nowiki>
$ cd /stuff/
$ cp openembedded/conf/local.conf.sample build/conf/local.conf
$ vi build/conf/local.conf
</nowiki></pre>

It is actually recommended to start smaller and keep local.conf.sample in the background and add entries from there step-by-step as you understand and need them. Please, do not just edit build/conf/local.conf.sample but actually READ it (read it and then edit).

For building a .dev branch, in your <nowiki>local.conf</nowiki> file, you should have at least the following three entries. Example for the Angstrom distribution and the Openmoko gta01 machine:
<pre><nowiki>
BBFILES = "/stuff/openembedded/packages/*/*.bb"
DISTRO = "angstrom-2008.1"
MACHINE = "om-gta01"
</nowiki></pre>

If you choose to install OE in your home directory, modify local.conf to refer to the OE paths as /home/<username>/ rather than ~/. It does not find the *.bb packages otherwise.

== Setup the environment ==
One of the four command sets below will need to be run every time you open a terminal for development. (You can automate this in ~/.profile, /etc/profile, or perhaps use a script to set the necessary variables for using [[BitBake]].)

If you followed the recommendation above to use [[BitBake]] from svn:
<pre><nowiki>
$ export BBPATH=/stuff/build:/stuff/openembedded
$ export PATH=/stuff/bitbake/bin:$PATH
</nowiki></pre>

If you installed [[BitBake]]:
<pre><nowiki>
$ export BBPATH=/stuff/build:/stuff/openembedded
</nowiki></pre>

Alternative syntax for those using the tcsh shell (e.g FreeBSD):
<pre><nowiki>
$ setenv PATH "/stuff/bitbake/bin:"$PATH
$ setenv BBPATH "/stuff/build:/stuff/openembedded:"$BBPATH
</nowiki></pre>

== Start building ==
The primary interface to the build system is the <nowiki>bitbake</nowiki> command (see the bitbake users manual). <nowiki>bitbake</nowiki> will download and patch stuff from the network, so it helps if you are on a well connected machine.

Note that you should issue all bitbake commands from inside of the <nowiki>build/</nowiki> directory, or you should override TMPDIR to point elsewhere (by default it goes to <nowiki>tmp/</nowiki> relative to the directory you run the tools in).

<tt>bitbake</tt> might complain that there is a problem with the setting in <tt>/proc/sys/vm/mmap_min_addr</tt>.
Needs to be set to zero. You can do it (as root) by the following:
<pre>
echo 0 > /proc/sys/vm/mmap_min_addr
</pre>
(editing the file won't help). Alternatively, some systems provide the sysctl.conf file to set this permanently.

<pre>
vm.mmap_min_addr=0
</pre>

Here are some example invocations:

Building a single package (e.g. nano):

<pre><nowiki>
$ bitbake nano
</nowiki></pre>

Building package sets (e.g. task-base):

<pre><nowiki>
$ bitbake task-base
</nowiki></pre>

''Special note for'' <nowiki>task-base</nowiki>: you may need additional setup for building this very one task. More details in [[ZaurusKernels]]

Building a group of packages and deploying them into a rootfs image:

GPE:

<pre><nowiki>
$ bitbake gpe-image
</nowiki></pre>

OPIE:

<pre><nowiki>
$ bitbake opie-image
</nowiki></pre>

('''NOTE:''' kergoth says it will take about 4GB of disk space to build an opie or gpe image for one architecture)

('''NOTE:''' if you are using your custom kernel - set "Use the ARM EABI to compile the kernel (AEABI)" option in "Kernel Features")

See the /stuff/openembedded/packages/meta/ directory if you're curious about what meta/task and image targets exist.

Building every package in the repository ('''NOTE:''' This will take a ''very'' long time and needs approx. 35 GB disk space):

<pre><nowiki>
$ bitbake world
</nowiki></pre>

Building a single package, bypassing the long parse step (and therefore its dependencies--use with care):

<pre><nowiki>
$ bitbake -b /stuff/openembedded/packages/blah/blah.bb
</nowiki></pre>

See [[UsefulTargets]] for a description of some of the more useful meta-packages. You will typically need at least one of the base images (<nowiki>bootstrap-image</nowiki>, <nowiki>opie-image</nowiki> or <nowiki>gpe-image</nowiki>), and if and only if you're building for an [http://wiki.openzaurus.org/Main_Page OpenZaurus] target requiring an installer image (such as C3000), an additional <nowiki>pivotboot-image</nowiki>.

Output of the build process (temporary files, log files and the binaries) all ends up in the <nowiki>tmp</nowiki> directory. Most interesting is probably the <nowiki>tmp/work/</nowiki> directory. Just have a look around the [[DirectoryStructure]].

Images generated by building package groups like <nowiki>opie-image</nowiki> or <nowiki>pivotboot-image</nowiki> are placed in the <nowiki>tmp/deploy/images/</nowiki> directory. Individual ipkg packages are put in <nowiki>tmp/deploy/ipk</nowiki>.

== Adding Packages ==
# Create [[bbfile]].
# Try building it locally.
# Fix eventual problems.
# Send .[[bbfile]] or an [[OePatch]] to the [http://wiki.openembedded.net/index.php/Mailing_Lists openembedded-devel mailing list]. Please note that changes should comply with the [[Commit_Policy | commit policy]].

= Problems =
Try to solve problems first by checking that you have done everything right, that nothing has changed from this description and that you have the latest code (see [[GitPhraseBook]]). Look also in the log file (referenced in any error message you will receive). If you still have problems, try checking [[PossibleFailures]] and [http://www.openembedded.org/wiki/OeFaq#builderrors common build errors].
Above links are dead, you can try the [[:Category:FAQ]]. If problems persist, ask on [[IRC]] or in the [[Mailing lists|openembedded mailing list]].

The Openembedded metadata is changing constantly. This implies several things:

# Once you have a "known good" version that works well on your system, keep it! To update, clone a new copy; don't overwrite that working version until it's known to be safe.
# To resolve build problems, "git pull" is your good friend. Many times, the issues will already be fixed in the current tree.
# Not all metadata updates cause the local caches to update correctly. Sometimes you'll need to remove the ".../tmp" work directory and rebuild from scratch.
# Similar issues apply to the package sources you download.

= Portability issues =
Make sure to set <nowiki>TARGET_OS</nowiki> to something other than linux in local.conf if your host isn't linux.

GNU extensions to tools are often required. Symlink GNU patch, make, and cp (from fileutils), chmod, sed, find, tar, awk into your OE development path.

FreeBSD 4 users: Perl 5.0 is too old. A more recent perl must be available as <nowiki>/usr/bin/perl</nowiki>. Unfortunately just having more recent perl in the path isn't good enough. Some scripts are hard-coded for <nowiki>/usr/bin/perl</nowiki>. You can test for which perl you're using by typing perl -v. see /usr/ports/UPDATING for instructions on updating perl. Don't forget to do a use.perl port as instructed in /usr/ports/UPDATING

FreeBSD users: Set <nowiki>BUILD_OS</nowiki> in local.conf to freebsdN where N is your major version number. At least the cross gcc wants this.

FreeBSD users: The build process of glibc uses a very long command line at some places. Increase ARG_MAX to at least 131072, by editing /usr/sys/sys/syslimits.h and recompile your kernel (and reboot).

= Productivity notes =
Use the interactive bitbake mode ("bitbake -i") to speed up work when debugging or developing .bb files. Remember to run "parse" at the prompt first. Go!

If you want to save some compile time or are interested in additional tweaks to local.conf take a look at the [[AdvancedConfiguration]] page.

[[Category:User]]

OEandYourDistro

2008-11-18T11:35:43Z

Mwelchuk: Undo revision 813 by 85.120.220.27 (Talk)

See [[RequiredSoftware]] for the list of the software required by Openembedded.

= Using OpenEmbedded on Linux systems =

== deb-based distributions ==

The easiest way is via [http://blog.leggewie.org/?p=39 apt-get'able Openembedded] which will pull the OE meta-data for you and keep it up-to-date. Plus, it makes sure all necessary software for cross-compilation is installed. Easy as 1-2-3.

=== Debian ===

==== Mandatory packages ====

It is possible that not all software is available in a recent enough version for etch. Try backports if necessary.

apt-get install ccache sed wget cvs subversion git-core \
coreutils unzip texi2html texinfo libsdl1.2-dev docbook-utils \
gawk python-pysqlite2 diffstat help2man

'''Git'''

On debian you may have to run

update-alternatives --config git (as root)

and select /usr/bin/git-scm to provide git instead of /usr/bin/git.transition. This is not necessary in sid

==== Complementary packages ====

<pre><nowiki>
apt-get install libxml2-utils xmlto python-psyco
</nowiki></pre>

OPTIONAL: these packages and their dependencies need to be installed in order to build the bitbake documentation (warning: over 160MB of installed packages).

<pre><nowiki>
apt-get install docbook
</nowiki></pre>
This package is necessary to build some packages (in particular the esound documentation needs it).

=== Ubuntu ===

Ubuntu is based on Debian and instructions above for [[#deb-based distributions|Debian]] apply here as well. Make sure that you have the universe repositories in your apt configuration.

* Check that /bin/sh (ls -l /bin/sh) is not symbolically linked to dash. "dash" is a POSIX compliant shell that is much smaller than "bash" -- however some broken shell scripts still make use of bash extensions while calling into /bin/sh. To work around this issue call "''sudo dpkg-reconfigure dash''" and select No when it asks you to install dash as /bin/sh.
* You can also install Psyco Python JIT compiler to speed up BitBake. Psyco works on 32-bit x86 platforms only. "''aptitude install python-psyco''

== rpm-based distributions ==

=== Mandriva Linux ===

Follow the Debian instructions, only using `urpmi` instead of `apt-get install`. Also, `ccache` is not an official Mandriva package. You can find it in the contrib section of any Mandriva mirror or seach for it using the Mandriva Club rpm database [http://rpms.mandrakeclub.com]. You may need libpythonV.V-devel for bitbake setup instead of python-dev.
If you're building a 2.6 kernel, you also need the glibc-static-devel package.

with Mandriva Linux 2006, you need to issue the following command:

<pre><nowiki>
urpmi python python-devel python-psyco ccache patch m4 sed bison make wget bzip2 \
cvs gawk glibc-devel gcc-c++ subversion sharutils coreutils docbook-utils openjade \
quilt pcre-devel unzip glibc-static-devel
</nowiki></pre>

=== openSUSE instructions ===

Use zypper to install the required packages:

zypper in subversion git python help2man diffstat wget gcc gcc-c++ libstdc++ glibc-devel

These packages may be useful as well: ccache, bison and [http://software.opensuse.org/search?baseproject=ALL&p=1&q=gcc33 gcc33] (for faster build using ASSUME_PROVIDED), gtk2-devel (in case your build will fail on missing gdk-pixbuf-csource), bc (for collie kernel), ncurses-devel (if you want to call kernel menuconfig). python psyco package is optional.

=== Fedora ===

==== Fedora Core 2/3 ====
Much of the following is probably already installed, but you can check with the following commands. You may want to use the yum.conf located at http://www.fedorafaq.org/. Note, this has not been tested yes as I am in the process of setting up a development environment.

<pre><nowiki> yum install python patch m4 sed make docbook* openjade glibc-devel xmlto</nowiki></pre>

* `yum install ccache` (not required, also not a FC3 package)

* psyco: Download psyco-1.4-src.tar.gz (or later) and extract it. Go to the psycho top-level directory and run: `python setup.py install`.

* patch: FC3 default version should be enough. Optionally, install SuSe 9.1 package of it.

==== Fedora Core 4 ====
Almost all required packages for Openembedded are available in Fedora Core 4 and the Fedora Extras for Core 4. You can download them from <http://download.fedora.redhat.com/pub/fedora/linux/core> and <http://download.fedora.redhat.com/pub/fedora/linux/extras>. Check <http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4> for updates on the Core 4 packages.

Apart from the usual (native) development packages like gcc and binutils, you should check that you have the following RPM's installed:

* bison
* ccache (not required, but advised to speed up building)
* docbook* packages
* libpcre
* m4
* make
* openjade
* patch
* PyQt
* python
* python-psyco
* sed
* xmlto
* quilt (not required as OE builds it by itself, but install it if you want to use gquilt)

Use apt, synaptic, up2date or yum to automagically retrieve these packages or download and install them manually (lots of work).

==== Fedora Core 5/6 ====

Commands I used to install OE pre-requisites on FC5/6

This long command will ensure all pre-requisites are installed (patch is 2.5.4, not 2.5.9, but appears to work).

<pre><nowiki>
su -c "yum install python m4 make wget curl ftp cvs subversion tar bzip2 gzip unzip python-psyco ccache perl texinfo texi2html diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git quilt groff linuxdoc-tools patch gcc gcc-c++ python-sqlite2 help2man"
</nowiki></pre>

or download the metapackage http://www.openembedded.org/dl/packages/rpm/openembedded-essential-1.1-1.noarch.rpm (may be out of date).

then do

<pre><nowiki>
su -c "yum localinstall openembedded-essential-1.1-1.noarch.rpm"
</nowiki></pre>

There are also rpm and src.rpm packages of bitbake 1.6.2 at http://www.openembedded.org/dl/packages/rpm/ pending a later version in Extras, currently 1.6.0.

Update - Current FC6 version is patch-2.5.4-29.2.2 as of this writing and works-for-me (see revision history for build instructions if current patch does not work for you).

I didn't install SGML tools. Please add if you know how

Update - Since about 2002 sgml-tools has apparently been replaced by linuxdoc-tools for FC.

==== Fedora 7 ====

This long command will ensure all pre-requisites are installed (patch is 2.5.4, not 2.5.9, but appears to work).

<pre><nowiki>
su -c "yum install python m4 make wget curl ftp cvs subversion tar bzip2 gzip unzip python-psyco ccache perl texinfo texi2html diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git quilt groff linuxdoc-tools patch linuxdoc-tools gcc gcc-c++ help2man perl-ExtUtils-MakeMaker"
</nowiki></pre>

(if this is hard to copy from this HTML page, go to edit mode and copy from editor)

=== CentOS 4.4 / Red Hat Enterprise Linux 4 ===
May also work for true EL4 or Scientific Linux - another RHEL rebuild

Even with several optional and 3rd party yum repos enabled (centosplus, kbsingh, RPMforge/Dag, Dries) a number of required packages are too old or unavailable for CentOS4. [It should be possible to use other package managers including apt/synaptic, up2date, and smart to get the required packages. The following assumes yum.]

I re-built the following SRPMS (with "$ rpmbuild --rebuild ..."):
* boost-1.33.1-10.fc5.src.rpm
* bitbake-1.6.2-1.src.rpm (Latest tarball from http://developer.berlios.de/projects/bitbake/ + modified spec from bitbake-1.6.0-2.fc7.src.rpm)

Might also want to try the rpm and src.rpm packages of bitbake 1.6.2 at http://www.openembedded.org/dl/packages/rpm/ - I have not.

Extra requirements for the builds included rpmdevtools, xmlto, and lynx.

I put packages in a local repo so I can do "yum install ...", otherwise can do "yum localinstall foo.1.2.3.noarch.rpm ...". It may be necessary to temporarily set "gpgcheck=0" in /etc/yum.conf to avoid complaints about unsigned packages.

For EL4 texi2html is available from the tetex package, currently tetex-2.0.2-22.EL4.7

Note that the the metapackage http://www.openembedded.org/dl/packages/rpm/openembedded-essential-1.1-1.noarch.rpm
should work except that it depends on texi2html.

Instead as root do

<pre><nowiki>
# yum install bison ccache coreutils cvs docbook-utils gawk git-core \
python quilt rpmlib sed subversion tetex texinfo unzip wget
</nowiki></pre>

I ended up with the following set of relevant packages after several iterations of building/updating to get "bitbake nano" to complete successfully:

* python-2.3.4-14.3
* m4-1.4.1-16
* make-3.80-6.EL4
* wget-1.10.2-0.40E
* curl-7.12.1-8.rhel4
* ftp-0.17-22
* cvs-1.11.17-9.RHEL4
* subversion-1.4.3-0.1.el4.rf
* tar-1.14-12.RHEL4
* bzip2-1.0.2-13.EL4.3
* gzip-1.3.3-16.rhel4
* unzip-5.51-7
* python-psyco-1.5-3.el4.kb
* ccache-2.4-1.2.el4.rf
* perl-5.8.5-36.RHEL4
* texinfo-4.7-5.el4.2
* tetex-2.0.2-22.EL4.7
* diffstat-1.34-0_6.el4.at
* openjade-1.3.2-16_9.el4.at
* docbook-style-dsssl-1.78-4
* docbook-style-xsl-1.65.1-2
* docbook-dtds-1.0-25
* docbook-utils-0.6.14-4
* sed-4.1.2-5.EL4
* bison-1.875c-2
* bc-1.06-17.1
* glibc-devel-2.3.4-2.25
* gcc-3.4.6-3
* binutils-2.15.92.0.2-21
* pcre-4.5-3.2.RHEL4
* pcre-devel-4.5-3.2.RHEL4
* git-1.4.4.2-2.el4.kb
* bitbake-1.6.2-1

== other Linux distributions ==

=== Gentoo instructions ===

On Gentoo 2008.0 the bitbake package is masked, so you'll need to update /etc/portage/package.keywords.

<pre><nowiki>
echo 'dev-embedded/bitbake ~x86' >> /etc/portage/package.keywords
</nowiki></pre>

<pre><nowiki>
emerge -n \
bitbake \
psyco \
ccache \
patch \
make \
sed \
dev-lang/python \
m4 \
bison \
cvs \
openjade \
quilt \
sgmltools-lite \
docbook-xml-dtd \
docbook-dsssl-stylesheets \
xmlto \
docbook-sgml-utils \
libpcre \
boost \
subversion \
texi2html
</nowiki></pre>

=== Ark Linux 2007.1 ===
[http://www.arklinux.org/ Ark Linux] is a modern distribution well suited for Openembedded development. Footprint only 2.1G.

Required steps:

1) install required packages
<pre><nowiki>
apt-get install devel-core diffstat texi2html cvs subversion git texinfo psyco python-devel python-encodings python-sqlite
</nowiki></pre>

2) upgrade
<pre><nowiki>
apt-get update
apt-get upgrade

The following packages will be REPLACED:
texi2html (by tetex-texi2html)
The following NEW packages will be installed:
tetex-texi2html
</nowiki></pre>

3) help2man

help2man is missing from the ArkLinux repositories. The [http://www.gnu.org/software/help2man/ sources] must be configured, compiled and installed. The compilation of help2man requires the installation of some additional packages:

apt-get install gettext-devel gettext-tools perl-Locale-gettext

4) finally create your OE tree and provide bitbake (see [[Getting Started]] instructions)

=== Arch Linux (Duke) ===

Most of the packages are available in the repositories.

<pre><nowiki>
sudo pacman -S psyco ccache patch make sed python m4 bison cvs quilt sgmltools-lite docbook-xml xmlto pcre boost jade git texinfo
</nowiki></pre>

In Arch Linux the install command is in /bin/install. Since most of Linux distribution assume that install is located in /usr/bin/install, you have to create a symlink:

<pre><nowiki>
sudo ln -s /bin/install /usr/bin/install
</nowiki></pre>

You can build BitBake by using this PKGBUILD:
<pre><nowiki>
pkgname=bitbake
pkgver=1.8.4
pkgrel=1
pkgdesc="A simple tool for task execution derived from Gentoo's portage"
url="http://developer.berlios.de/projects/bitbake/"
arch=('i686')
license=('GPL' 'custom')
depends=('python')
source=(http://download.berlios.de/bitbake/${pkgname}-${pkgver}.tar.gz)
md5sums=('508d9a61c635d469be8facc95151158b')

build() {
cd ${startdir}/src/${pkgname}-${pkgver}
python setup.py install --root=${startdir}/pkg

# Install vim extensions
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/contrib/vim/ftdetect/bitbake.vim \
${startdir}/pkg/usr/share/vim/ftplugin/bitbake.vim
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/contrib/vim/syntax/bitbake.vim \
${startdir}/pkg/usr/share/vim/syntax/bitbake.vim

# Handle MIT license
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/doc/COPYING.MIT \
${startdir}/pkg/usr/share/licenses/${pkgname}/COPYING.MIT
}
</nowiki></pre>

= Using OpenEmbedded on FreeBSD and other NON Linux Systems =

to be done, maybe there is some information in the [http://oe.linuxtog.org/wiki old wiki]

== FreeBSD ==

* Python == /usr/ports/lang/python
* GNU Patch == /usr/ports/devel/patch
* GNU m4 == /usr/ports/devel/m4
* GNU make == /usr/ports/devel/gmake
* wget == /usr/ports/ftp/wget
* Psyco JIT Compiler == /usr/ports/devel/py-psyco
* ccache == /usr/ports/devel/ccache
* GNU sed == /usr/ports/textproc/gsed
* Bison == /usr/ports/devel/bison
* GCC 2.95.3 == /usr/ports/lang/gcc295
* bc == already in FreeBSD
* PyQt == /usr/ports/x11-toolkits/py-qt
* glibc headers (ignore)
* subversion == /usr/ports/devel/subversion
* git == /usr/ports/devel/git
* pcre == /usr/ports/devel/pcre

Ports has also has these: fileutils, jade, docbook, dsssl-docbook-modular, sgmltools

== Using OpenEmbedded on Mac OS X ==

to be done, maybe there is some information in the [http://oe.linuxtog.org/wiki old wiki]

= Using OpenEmbedded on Windows/Cygwin Systems =

Building Openembedded on Windows is currently unsupported, but [http://oe.linuxtogo.org/wiki/BuildOnCygwin work is in progress] to support buidling of meta-toolchain.bb on Windows/Cygwin hosts.