Building and running embedded Linux .NET applications from first principles: Difference between revisions

From Yocto Project
Jump to navigationJump to search
No edit summary
No edit summary
Line 73: Line 73:
== Build an example project on the host for testing (optional) ==
== Build an example project on the host for testing (optional) ==


=== Autotools ===
=== Building with autotools ===


The most straightforward way to compile non-.NET projects for different targets within Yocto is to make use of [http://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/index.html autotools]
The most straightforward way to compile non-.NET projects for different targets within Yocto is to make use of [http://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/index.html autotools]
Line 124: Line 124:


This will give you a basic Windows Forms window title
This will give you a basic Windows Forms window title
[[File:Monohelloworld.png|800px]]
So you have now shown that you can successfully fetch configure and build the project on the host.  
So you have now shown that you can successfully fetch configure and build the project on the host.  


Next we will look at how Yocto automates the this process of fetching, configuring and building, then also installs and packages the output files.
Next we will look at how Yocto automates the this process of fetching, configuring and building, then also installs and packages the output files.


== Adding new recipes to the build system ==
=== Building with xbuild ===
 
Many individuals develop with Visual Studio, Mono Develop, Xamarin Studio or other similar integrated development environments (IDEs).
 
Mono provides <code>xbuild</code> which is the Mono implementation of Microsoft's <code>msbuild</code>, discussed [http://mono-project.com/Microsoft.Build here].
 
In essence this enables a developer to create a solution of projects within their IDE of choice, then use xbuild to build within the Mono environment.
 
A useful workflow to follow may be to develop locally with an IDE of choice, commit to a git repository upon release, then use a Yocto recipe to build and package that release into an existing image, or for provision to a package feed for update to existing targets in the field.
 
The <code>mono-helloworld</code> project discussed [[#Building with autotools|above]] also provides a solution and project files to support build with <code>xbuild</code>, or indeed with an IDE such as Visual Studio.
 
If you have already built the examples using <code>autotools</code> remove the folder and start again.
 
  $ cd ~/host
  $ rm -Rf mono-helloworld
 
Check out the mono-helloworld project again
 
  $ git clone https://github.com/DynamicDevices/mono-helloworld
 
Run xbuild. (As you might guess from the name of the .sln file you could clone this example project to a Windows host and open it up with Visual Studio, and in fact that is how it was created)
 
  $ xbuild /p:Configuration=Debug mono-helloworld_vs2010.sln
 
This results in a number of new files, including two new Mono/.NET executables in <code>bin/Debug</code> <code>helloworld.exe</code> and <code>helloworldform.exe </code>
 
You can run the first with
 
  $ mono bin/Debug/helloworld.exe
 
It will output
 
HelloWorld
 
You can run the second with


There are different ways to add new recipes to Yocto.  
  $ mono bin/Debug/helloworldform.exe


One way is to simply create a new recipe_version.bb file in a recipe-foo/recipe folder within one of the existing layers used by Yocto.
Depending on your host environment (e.g. using SSH) you may need to explicitly set the <code>DISPLAY</code> variable for this to work, with


=== Placing a recipe in an existing layer (example only) ===
  $ export DISPLAY=:0
  $ mono bin/Debug/helloworldform.exe


For example you could
This will give you a basic Windows Forms window title


  $ cd ~/yocto/poky-daisy-11.0.0/meta-yocto
[[File:Monohelloworld.png|800px]]
  $ mkdir recipes-example
  $ mkdir bbexample
  $ cd bbexample
  $ wget https://raw.githubusercontent.com/DynamicDevices/meta-example/master/recipes-example/bbexample/bbexample_1.0.bb


The recipe will then be picked up by bitbake and you can build the recipe with
So you have now shown that you can successfully fetch configure and build the project on the host.


  $ cd ~/yocto/poky-daisy-11.0.0/build-qemux86
Next we will look at how Yocto automates the this process of fetching, configuring and building, then also installs and packages the output files.
  $ bitbake bbexample


=== Using a new layer for recipes ===
== Adding the <code>meta-mono</code> layer to the Yocto build system ==


A preferred method for adding recipes to the build environment, and the method you should use with this guide, is to place them within a new layer.  
A preferred method for adding recipes to the build environment, and the method shown with this guide, is to place them within a new layer.  


Layers isolate particular sets of build meta-data based on machine, functionality or similar, and help to keep the environment clean.
Layers isolate particular sets of build meta-data based on machine, functionality or similar, and help to keep the environment clean.


An example layer, meta-example, has been created using the <code>yocto-layer</code> command and committed into a GitHub repository [https://github.com/DynamicDevices/meta-example here].
The <code>meta-mono</code> layer contains Mono specific recipes to support execution of .NET applications on target boards. The layer can be found [http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono here].


To use a new layer such as this you first clone the git repository and then add the layer to your bitbake configuration in <code>conf/bblayers.conf</code>
To use a new layer such as this you first clone the layer from its git repository and then add the layer to your <code>bitbake</code> configuration by editing <code>conf/bblayers.conf</code>


   $ cd ~/yocto/poky-daisy-11.0.0
   $ cd ~/yocto/poky-daisy-11.0.0
   $ git clone https://github.com/DynamicDevices/meta-example
   $ git clone git://git.yoctoproject.org/meta-mono
   $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86
   $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86
   $ nano conf/bblayers.conf
   $ nano conf/bblayers.conf
Line 189: Line 223:
     /home/user/yocto/poky-daisy-11.0.0/meta-yocto \
     /home/user/yocto/poky-daisy-11.0.0/meta-yocto \
     /home/user/yocto/poky-daisy-11.0.0/meta-yocto-bsp \
     /home/user/yocto/poky-daisy-11.0.0/meta-yocto-bsp \
     /home/user/yocto/poky-daisy-11.0.0/meta-example \
     /home/user/yocto/poky-daisy-11.0.0/meta-mono \
     "
     "


Line 209: Line 243:
   meta-yocto
   meta-yocto
   meta-yocto-bsp    = "<unknown>:<unknown>"
   meta-yocto-bsp    = "<unknown>:<unknown>"
   meta-example      = "master:da011ba5dda914dc8bc3768356e2a9fd726383bc"
   meta-mono        = "master:cb4998b3fbb7912468df8fc06d692fa872a21947"


== Build an example package based on a git repository commit ==
== Build an image including Mono/.NET support ==


==== The bbexample recipe ====
The <code>meta-mono</code> layer includes a recipe to build an image <code>core-image-mono</code> based on the Yocto standard image <code>core-image-sato</code>
The recipe we are going to build is [https://github.com/DynamicDevices/meta-example/blob/master/recipes-example/bbexample/bbexample_1.0.bb /home/user/yocto/poky-daisy-11.0.0/meta-example/recipes-example/bbexample/bbexample_1.0.bb].


The main points to note are that
To build this image


* <code>SRC_URI</code> is set to point to the git repository
  $ bitbake core-image-mono
* <code>SRC_REV</code> corresponds to a particular commit into that repository (it is also possible to specify a branch)
* There is a <code>LICENSE</code> variable defined to indicate the type of license to the build environment (MIT) and another variable,
* <code>LIC_FILES_CHKSUM</code>, points to a file within the source tree that will be retrieved, with a corresponding md5 check-sum to ensure that somebody has actually verified the source license file corresponds to that given to the build environment. Also that this file, and thus potentially the license, has not changed over time.
* The source directory for the recipe build, <code>${S}</code> is set to <code>"${WORKDIR}/git"</code> which is the default location to which the retrieved git repository will be checked out and unpacked.
* We inherit a class called <code>autotools</code> which provides the functionality to enable <code>bitbake</code> to automatically build projects with <code>autotools</code> support.
* There is a marked absence of a <code>do_install</code> function, which you may have seen elsewhere, as this is dealt with by the <code>autotools</code> support


To start the build
This may take a while, even if you have already built <code>core-image-minimal<code> as additional GUI support packages need to be built.


  $ bitbake bbexample
The <code>core-image-mono</code> recipe can be found [http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/images/core-image-mono.bb here] and pulls in an include file from [http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/images/core-image-mono.inc here].


Bitbake will work through a number of tasks, including fetching the source from the git repository, unpacking, configuring, compiling, installing and packaging the output.
You can see in the include file that extra packages are added to the standard <code>core-image-sato</code> image.


As we are building for the emulator, <code>qemux86</code>, and are building RPM packages (the default), output packages will be in
  IMAGE_INSTALL += "libgdiplus mono mono-helloworld"
 
This is how you would add Mono support to your image within a recipe, or within a .bbappend file. In fact it should only be necessary to add the <code>mono</code> package as this has a dependency on <code>libgdiplus</code> and it is not necessary to have the examples unless you wish to for testing purposes.


  ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm/i586/bbexample-1.0-r0.0.i586.rpm
The <code>mono-helloworld</code> recipe included here shows how to build the example project using <code>autotools</code>. For details see the recipe itself [http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mono-helloworld/mono-helloworld_1.1.bb here], and more importantly the include file it pulls in [http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mono-helloworld/mono-helloworld.inc here].


For other machine targets the folder and suffix <code>i586</code> will be replaced by a different machine-specific name. To find the location of the package you can use
You could choose to replace <code>mono-helloworld</code> with <code>mono-helloworld-xbuild</code> which as the name suggests shows how to build the eaxmple project with <code>xbuild</code>.


  $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm
== Testing the .NET executable on an emulated target==
  $ find -name bbexample*


(Or instead of <code>bbexample</code> use a prefix of the name of the recipe you are building)
Having built <code>core-image-mono<code> you can then run it up under <code>qemu</code>


This will show you both the main package and the subsidiary packages which <code>bitbake</code> builds for each recipe such as -dev, -debug, -staticdev and so forth. For more on this see [http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html here]
To run up the image, simply use
$ runqemu qemux86


Having found the package you can check that the contents are as expected with
This will boot the emulator, load up the image, you'll see a kernel loading and then a basic user interface.


  $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm
If you find that your keymap is incorrect you might wish to set this explicitly, for example
  $ rpm -qlp i586/bbexample-1.0-r0.0.i586.rpm


For the <code>bbexample</code> recipe we expect to see the cross-compiled executable <code>bbexample</code> and the shared library it needs <code>libbbexample.so.1</code>
$ runqemu qemux86 qemuparams='-k en-gb'


  /usr
or
  /usr/bin
  /usr/bin/bbexample
  /usr/lib
  /usr/lib/libbbexample.so.1
  /usr/lib/libbbexample.so.1.0.0


You could then add the output of this recipe to your output image by adding something like this to your <code>conf/local.conf</code>
$ runqemu qemux86 qemuparams='-k en-us'


  IMAGE_INSTALL_append = " bbexample"
Open up a terminal window using the appropriate icon, Log into the emulator as 'root', no password and run the examples.


Alternatively you could make the new packages available to existing target systems using the Yocto <code>package-management</code> tools such as <code>smart</code>.
You can run the first with


== Build an example package based on a remote source archive ==
  $ mono helloworld.exe


The recipe we are going to build is [https://github.com/DynamicDevices/meta-example/blob/master/recipes-example/bbexample/bbexample-rt_1.0.bb /home/user/yocto/poky-daisy-11.0.0/meta-example/recipes-example/bbexample/bbexample-rt_1.0.bb].
Or alternatively the recipe installs a script to wrap use of Mono, so you can use the form


This is based on the previous recipe that builds from a git checkout, with the major difference being we are building from a remote tarball.
  $ helloworld


This tarball may, in theory, contain any sources we wish to build, although sometimes build failures may require patching of the sources, and if <code>autotools</code> is not provided then the recipe may well have to be extended with a <code>do_install</code> function to ensure appropriate files are installed, and the FILES_${PN} variable modified to ensure installed files are correctly packaged.
This will output


For this simple example the git commit used above has been tagged 'bbexample-v1.0' in the GitHub repository, which causes GitHub to provide a release source archive.
HelloWorld


This tagged archive is what we set in the recipe <code>SRC_URI</code> to retrieve and build.
You can run the second with


The main points to note are that
  $ mono ??? helloworldform.exe


* <code>SRC_URI</code> is set to point to the remote source archive
or


   SRC_URI = "https://github.com/DynamicDevices/bbexample/archive/bbexample-v${PV}.tar.gz"
   $ helloworldform


Ideally we would use both of the variables ${PN} and ${PV} which would be replaced by the recipe name and recipe version, and could usually be expected to map to the naming convention employed for the source archive file. This makes the recipe more generic and easier to update to a new version of the source code by renaming the recipe .bb file. However as I am using a slightly different recipe name, 'bbexample-rt' I have hard-coded the names here.
Depending on your host environment (e.g. using SSH) you may need to explicitly set the <code>DISPLAY</code> variable for this to work, with


* There is no <code>SRC_REV</code> here but instead we have <code>SRC_URI</code> values for md5sum and an sha256sum check-sums
   $ export DISPLAY=:0
 
   $ mono ??? helloworldform.exe
As you would expect, these correspond to the particular check-sums generated by those algorithms when run over the entire archive.
 
You can generate these by hand by retrieving the file yourself, running <code>md5sum archivename</code> and <code>sha256sum archivename</code> but it is easier to set these incorrectly and let <code>bitbake</code> retrieve the archive and error on incorrect checksums and which point it will tell you what the lines should be.
 
   SRC_URI[md5sum] = "a040115592f4200188a805368d9456ff"
  SRC_URI[sha256sum] = "589b22fc6c2c0b266223c5988f0e33f5c2f03a114da9145e722e3552a0edd308"
 
You should be aware that sometimes maintainers re-release archives under the same name but with updated contents. Should this happen the check-sum check will fail and you will have to look into whether this is because of a corrupted download (check the downloaded archive in ~/yocto/poky-daisy-11.0.0/build_qemux86/downloads) or because the archive has actually been changed.
 
* There is a <code>LICENSE</code> variable defined to indicate the type of license to the build environment (MIT) and another variable,
* <code>LIC_FILES_CHKSUM</code>, points to a file within the source tree that will be retrieved, with a corresponding md5 check-sum to ensure that somebody has actually verified the source license file corresponds to that given to the build environment. Also that this file, and thus potentially the license, has not changed over time.
 
* The source directory for the recipe build, <code>${S}</code> is set to <code>"bbexample-bbexample-v${PV}"</code> which corresponds to the path to the source-code when extracted from the archive generated by GitHub. This looks slightly strange but is due to the vagaries of the way the git repository tag was added, as this is embedded by GitHub within the archive.
 
  # Make sure our source directory (for the build) matches the directory structure in the tarball
  # A tagged tarball from github contains a folder which includes the github tag, so deal with it here
  S = "${WORKDIR}/bbexample-bbexample-v${PV}"
 
* We inherit a class called <code>autotools</code> which provides the functionality to enable <code>bitbake</code> to automatically build projects with <code>autotools</code> support.
* There is a marked absence of a <code>do_install</code> function, which you may have seen elsewhere, as this is dealt with by the <code>autotools</code> support
 
To start the build
 
  $ bitbake bbexample
 
Bitbake will work through a number of tasks, including fetching the source archive, unpacking, configuring, compiling, installing and packaging the output.
 
There may be some warnings shown as all three recipes <code>bbexample</code>, <code>bbexample-rt</code> and <code>bbexample-lt</code> are generating the same output and thus there is some collision of shared files. These warnings may be ignored.
 
As we are building for the emulator, <code>qemux86</code>, and are building RPM packages (the default), output packages will be in
 
  ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm/i586/bbexample-1.0-r0.0.i586.rpm
 
For other machine targets the folder and suffix <code>i586</code> will be replaced by a different machine-specific name. To find the location of the package you can use
 
  $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm
  $ find -name bbexample*
 
(Or instead of <code>bbexample</code> use a prefix of the name of the recipe you are building)
 
This will show you both the main package and the subsidiary packages which <code>bitbake</code> builds for each recipe such as -dev, -debug, -staticdev and so forth. For more on this see [http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html here]
 
Having found the package you can check that the contents are as expected with
 
  $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm
   $ rpm -qlp i586/bbexample-1.0-r0.0.i586.rpm
 
For the <code>bbexample</code> recipe we expect to see the cross-compiled executable <code>bbexample</code> and the shared library it needs <code>libbbexample.so.1</code>
 
  /usr
  /usr/bin
  /usr/bin/bbexample
  /usr/lib
  /usr/lib/libbbexample.so.1
  /usr/lib/libbbexample.so.1.0.0
 
You could then add the output of this recipe to your output image by adding something like this to your <code>conf/local.conf</code>
 
  IMAGE_INSTALL_append = " bbexample"
 
Alternatively you could make the new packages available to existing target systems using the Yocto <code>package-management</code> tools such as <code>smart</code>.
 
== Build an example package based on a local source archive ==
 
The recipe we are going to build is [https://github.com/DynamicDevices/meta-example/blob/master/recipes-example/bbexample/bbexample-lt_1.0.bb /home/user/yocto/poky-daisy-11.0.0/meta-example/recipes-example/bbexample/bbexample-lt_1.0.bb].
 
This is based on the previous recipe that builds from a remote source release, with the major difference being we are building from a local source tarball.
 
This tarball may, in theory, contain any sources we wish to build, although sometimes build failures may require patching of the sources, and if <code>autotools</code> is not provided then the recipe may well have to be extended with a <code>do_install</code> function to ensure appropriate files are installed, and the FILES_${PN} variable modified to ensure installed files are correctly packaged.
 
For this simple example the release source archive available from GitHub has been copied locally into the <code>meta-example</code> layer folder tree,
 
  yocto/poky-daisy-11.0.0/meta-example/recipes-example/bbexample/bbexample-lt-1.0/bbexample-v1.0.tar.gz
 
This local file is what we set in the recipe <code>SRC_URI</code> to copy across, unpack, patch (if necessary) and build.
 
The main points to note are that
 
* <code>SRC_URI</code> is set to point to a local file archive
 
  SRC_URI = "file://bbexample-v${PV}.tar.gz"
 
Ideally we would use both of the variables ${PN} and ${PV} which would be replaced by the recipe name and recipe version, and could usually be expected to map to the naming convention employed for the source archive file. This makes the recipe more generic and easier to update to a new version of the source code by renaming the recipe .bb file. However as I am using a slightly different recipe name, 'bbexample-lt' I have hard-coded the names here.
 
* We provide a search path to ensure <code>bitbake</code> can find the archive
 
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
 
In this case the above will expand to the following folder, which is where we have placed <code>bbexample-v1.0.tar.gz</code>, and thus <code>bitbake</code> will find it to unpack.
 
  ~/yocto/poky-daisy-11.0.0/meta-example/recipes-example/bbexample/bbexample-lt-1.0
 
* There is no <code>SRC_REV</code> here but instead we have <code>SRC_URI</code> values for md5sum and an sha256sum check-sums
 
As you would expect, these correspond to the particular check-sums generated by those algorithms when run over the entire archive.
 
You can generate these by hand by retrieving the file yourself, running <code>md5sum archivename</code> and <code>sha256sum archivename</code> but it is easier to set these incorrectly and let <code>bitbake</code> retrieve the archive and error on incorrect checksums and which point it will tell you what the lines should be.
 
  SRC_URI[md5sum] = "a040115592f4200188a805368d9456ff"
  SRC_URI[sha256sum] = "589b22fc6c2c0b266223c5988f0e33f5c2f03a114da9145e722e3552a0edd308"
 
You should be aware that sometimes maintainers re-release archives under the same name but with updated contents. Should this happen the check-sum check will fail and you will have to look into whether this is because of a corrupted download (check the downloaded archive in ~/yocto/poky-daisy-11.0.0/build_qemux86/downloads) or because the archive has actually been changed.
 
* There is a <code>LICENSE</code> variable defined to indicate the type of license to the build environment (MIT) and another variable,
* <code>LIC_FILES_CHKSUM</code>, points to a file within the source tree that will be retrieved, with a corresponding md5 check-sum to ensure that somebody has actually verified the source license file corresponds to that given to the build environment. Also that this file, and thus potentially the license, has not changed over time.
 
* The source directory for the recipe build, <code>${S}</code> is set to <code>"bbexample-bbexample-v${PV}"</code> which corresponds to the path to the source-code when extracted from the local archive. This looks slightly strange but is due to the vagaries of the way the git repository tag was added, as this is embedded by GitHub within the archive. Alternatively we could have repacked the archive with a cleaner folder hierarchy.
 
  # Make sure our source directory (for the build) matches the directory structure in the tarball
  # A tagged tarball from github contains a folder which includes the github tag, so deal with it here
  S = "${WORKDIR}/bbexample-bbexample-v${PV}"
 
* We inherit a class called <code>autotools</code> which provides the functionality to enable <code>bitbake</code> to automatically build projects with <code>autotools</code> support.
* There is a marked absence of a <code>do_install</code> function, which you may have seen elsewhere, as this is dealt with by the <code>autotools</code> support
 
To start the build
 
  $ bitbake bbexample
 
Bitbake will work through a number of tasks, including fetching the source archive, unpacking, configuring, compiling, installing and packaging the output.
 
There may be some warnings shown as all three recipes <code>bbexample</code>, <code>bbexample-rt</code> and <code>bbexample-lt</code> are generating the same output and thus there is some collision of shared files. These warnings may be ignored.
 
As we are building for the emulator, <code>qemux86</code>, and are building RPM packages (the default), output packages will be in
 
  ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm/i586/bbexample-1.0-r0.0.i586.rpm
 
For other machine targets the folder and suffix <code>i586</code> will be replaced by a different machine-specific name. To find the location of the package you can use
 
  $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm
  $ find -name bbexample*
 
(Or instead of <code>bbexample</code> use a prefix of the name of the recipe you are building)
 
This will show you both the main package and the subsidiary packages which <code>bitbake</code> builds for each recipe such as -dev, -debug, -staticdev and so forth. For more on this see [http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html here]
 
Having found the package you can check that the contents are as expected with
 
  $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86/tmp/deploy/rpm
  $ rpm -qlp i586/bbexample-1.0-r0.0.i586.rpm
 
For the <code>bbexample</code> recipe we expect to see the cross-compiled executable <code>bbexample</code> and the shared library it needs <code>libbbexample.so.1</code>
 
  /usr
  /usr/bin
  /usr/bin/bbexample
  /usr/lib
  /usr/lib/libbbexample.so.1
  /usr/lib/libbbexample.so.1.0.0
 
You could then add the output of this recipe to your output image by adding something like this to your <code>conf/local.conf</code>
 
  IMAGE_INSTALL_append = " bbexample"
 
Alternatively you could make the new packages available to existing target systems using the Yocto <code>package-management</code> tools such as <code>smart</code>.
 
== Recipe gotchas ==
 
=== Incorrect source folder ${S} ===
 
It is extremely important to make sure that the source folder, the <code>${S}</code> variable is set correctly.
 
When retrieving files from git repositories, or when archives are unpacked, it is entirely possible that the source folder default will not be correct for the actual unpacked location of the sources.
 
If this happens the build will fail, often with a message that the <code>LICENSE</code> file cannot be found, as this is checked early on in the unpack.
 
To check through this one option is to drop into a development shell with
 
  $ bitbake -c devshell recipename
 
This will drop you into the configured location of <code>${S}</code>. If the sources defined in <code>SRC_URI</code> seemed to be retrieved correctly but you see nothing in your devshell, excepting perhaps a <code>patches</code> folder, this is a good indication that the code has been unpacked into a different folder.
 
  $ cd ..
  $ ls
 
You often will see another folder in the directory level about <code>${S}</code> which contains the source code.
 
This being the case you need to exit your devshell and edit your recipe to modify the source directory to point to the correct location. e.g.
 
  ${S} = "${WORKDIR}/correctfoldername"
 
 
Dropping back into the devshell should then show the correct files, and you should be able to make progress with the build
 
=== Incorrect license checksum ===
 
This can occur, particularly when upgrading a recipe to use a new repository commit or source archive version, as the licensing file may have changed.
 
If this does occur it is important to check through the new licensing file to ensure that the build environment is still being given correct information on the type of license for the source code.
 
It may also be that a minor textual change has been made to the file (e.g. new copyright date) which doesn't affect the type of the license itself.
 
Having satisfied yourself that the <code>LICENSE</code> variable in the recipe reports the correct license type you can update the license checksum to that reported by <code>bitbake</code> by modifying <code>LIC_FILES_CHKSUM</code>
 
=== Incorrect source archive checksum ===
 
You should be aware that sometimes maintainers re-release archives under the same name but with updated contents. Should this happen the check-sum check will fail and you will have to look into whether this is because of a corrupted download (check the downloaded archive in ~/yocto/poky-daisy-11.0.0/build_qemux86/downloads) or because the archive has actually been changed.
 
* You can try removing the archive from the downloads folder, and the corresponding .done file. The archive will then be downloaded again which may work if there was a corrupt/interrupted download (although in my experience this occurrence is unlikely).
 
* Alternatively the archive may have changed and you may wish to use the new archive, in which case you will need to update the check-sums in the recipe to those you calculate yourself on the archive with <code>md5sum</code> and <code>sha256sum</code>, or simply use what <code>bitbake</code> calculates and provides for you in the log.
 
  SRC_URI[md5sum] = "???"
  SRC_URI[sha256sum] = "???"
 
* Lastly you may be able to source the correct archive file from a mirror or through Googling, in which case you can drop it into the <code>downloads</code> folder for use by <code>bitbake</code>
 
In the latter two cases you may wish to feed the issue back to the Yocto mailing list (or other relevant mailing list for the layer in which the recipe resides) as this type of thing means mirrored copies of primary sources become out of sync, and the layer/mirror maintainers may wish to address the issue.


=== Missing source archive ===
This will show a test Windows Forms form titled 'Hello World'


This is less of an issue than it has been in the past as primary sources are now mirrored in one or more locations, not least by the Yocto project itself.
???


You can also set up your own mirror sources, which is dealt with [[How_do_I#Q:How do I create my own source download mirror? | here]]
== Breakdown of an autotools recipe ==


However for a one-off missing archive it is often quickest and easiest to Google to find it, then drop it into the ~/yocto/poky-daisy-11.0.0/build_qemux86/downloads folder, creating an empty .done file with
TBD


  $ touch archivename.done
== Breakdown of an xbuild recipe ==


It should then be picked up and used by <code>bitbake</code>
TBD


== Feedback ==
== Feedback ==


This is a living document. Please feel free to send comments, questions, corrections to Alex Lennon [mailto://ajlennon@dynamicdevices.co.uk here]
This is a living document. Please feel free to send comments, questions, corrections to Alex Lennon [mailto://ajlennon@dynamicdevices.co.uk here]

Revision as of 10:31, 10 May 2014

[Work in progress]

Overview

This walk-through has the aim of taking you from a clean system through to including Mono in a build image with the meta-mono layer, then building and packaging an example .NET project for inclusion in that image.

You may already have Yocto installed and just be looking to work with recipes for the first time, in which case you can jump forward to the section you find most relevant,
such as building an example package on the host to test or building an example package from a git commit.

The following assumptions are made. You are:

  • familiar with basic Linux admin tasks
  • aware of the Yocto Project Reference Manual here.
  • using Ubuntu 12.04 LTS as your host build system
  • working with Yocto 1.6 (daisy) release

Obtain the required packages for your host system to support Yocto

First we will install the required host packages for Ubuntu as detailed in the quickstart, i.e.

 $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath libsdl1.2-dev xterm nano

Full details of system requirements and installation can be found in the Yocto Quickstart here

Also install Mono on your host system as we'll use it to build and run some examples for test later

 $ sudo apt-get install mono-complete
 $ mono --version

With Ubuntu 12.04 LTS this will install Mono version 2.10 which is now quite old (December 2011).

If you wish to install a newer build of Mono to your host system you can follow the instructions here.

 $ sudo add-apt-repository ppa:directhex/monoxide
 $ sudo apt-get update
 $ sudo apt-get install mono-complete
 $ mono --version

This will install Mono 3.2.1 (August 2013)

If you wish to use the absolute latest Mono then there are instructions you can follow to build a release tarball here and from git here. Be aware this may not be straightforward and that there can be issues, such as with missing files, if you follow this process.

Download and extract the Yocto 1.6 release

At the time of writing, the current release of Yocto (1.6) can be found here

 $ cd ~
 $ mkdir yocto
 $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/poky-daisy-11.0.0.tar.bz2
 $ tar xjvf poky-daisy-11.0.0.tar.bz2

This will get you the Yocto 1.6 base meta-data and the bitbake tool. You can also add in extra layers, usually of the form "meta-foo" to provide machine support and additional functionality.

Configure the build environment to build an emulator image

 $ cd ~/yocto/poky-daisy-11.0.0
 $ source oe-init-build-env build_qemux86

This will create a build tree in "build_qemux86" although you could use a different name if you so wish with no adverse effects.

It is entirely possible to have many build trees in parallel in different folders and to switch between them using oe-init-build-env.

oe-init-build-env will create a default configuration file in conf/local/conf which will build an emulator image suitable for execution with qemu

Build a baseline image

After configuring the environment you will be left in the build_qemux86 folder.

You should then build a baseline image, which will take some time (numbers of hours)

 $ bitbake core-image-minimal

Build an example project on the host for testing (optional)

Building with autotools

The most straightforward way to compile non-.NET projects for different targets within Yocto is to make use of autotools

Projects which support autotools provide a set of template files which are then used by the autotools to generate Makefiles and associated configuration files which are appropriate to build for the target environment.

Similarly it is possible to compile Mono/.NET projects using autotools

A very basic example 'Hello World' style project called mono-helloworld has been committed to GitHub here

If you take a look at the two source files helloworld.cs and helloworldform.cs you can see the first outputs a 'Hello World' message to the console, and the second creates a Windows Form titled 'Hello World'.

Discussion of autotools template configuration for Mono is outside the scope of this guide, but the mono-helloworld project is based on the mono-skel example which can be found in the Autotools section of the Mono Application Deployment guidelines here

The project itself builds two .NET executables, helloworldcode> and helloworldform respectively, the first of which is a console application and the second of which is a simple Windows Forms application.

To build the project on the host independently of Yocto first clone the example repository

 $ mkdir ~/host
 $ cd ~/host
 $ git clone https://github.com/DynamicDevices/mono-helloworld

Then run the autotools, configure the build, and make the project

 $ cd mono-helloworld
 $ ./autogen.sh
 $ ./configure
 $ make

Following a successful compilation you will have a number of new files in the root of the build folder.

There are two new .NET executables src/helloworld.exe and src/helloworldform.exe.

You can run the first with

 $ mono src/helloworld.exe

It will output

HelloWorld

You can run the second with

 $ mono src/helloworldform.exe

Depending on your host environment (e.g. using SSH) you may need to explicitly set the DISPLAY variable for this to work, with

 $ export DISPLAY=:0
 $ mono src/helloworldform.exe

This will give you a basic Windows Forms window title

Monohelloworld.png

So you have now shown that you can successfully fetch configure and build the project on the host.

Next we will look at how Yocto automates the this process of fetching, configuring and building, then also installs and packages the output files.

Building with xbuild

Many individuals develop with Visual Studio, Mono Develop, Xamarin Studio or other similar integrated development environments (IDEs).

Mono provides xbuild which is the Mono implementation of Microsoft's msbuild, discussed here.

In essence this enables a developer to create a solution of projects within their IDE of choice, then use xbuild to build within the Mono environment.

A useful workflow to follow may be to develop locally with an IDE of choice, commit to a git repository upon release, then use a Yocto recipe to build and package that release into an existing image, or for provision to a package feed for update to existing targets in the field.

The mono-helloworld project discussed above also provides a solution and project files to support build with xbuild, or indeed with an IDE such as Visual Studio.

If you have already built the examples using autotools remove the folder and start again.

 $ cd ~/host
 $ rm -Rf mono-helloworld

Check out the mono-helloworld project again

 $ git clone https://github.com/DynamicDevices/mono-helloworld

Run xbuild. (As you might guess from the name of the .sln file you could clone this example project to a Windows host and open it up with Visual Studio, and in fact that is how it was created)

 $ xbuild /p:Configuration=Debug mono-helloworld_vs2010.sln

This results in a number of new files, including two new Mono/.NET executables in bin/Debug helloworld.exe and helloworldform.exe

You can run the first with

 $ mono bin/Debug/helloworld.exe

It will output

HelloWorld

You can run the second with

 $ mono bin/Debug/helloworldform.exe

Depending on your host environment (e.g. using SSH) you may need to explicitly set the DISPLAY variable for this to work, with

 $ export DISPLAY=:0
 $ mono bin/Debug/helloworldform.exe

This will give you a basic Windows Forms window title

Monohelloworld.png

So you have now shown that you can successfully fetch configure and build the project on the host.

Next we will look at how Yocto automates the this process of fetching, configuring and building, then also installs and packages the output files.

Adding the meta-mono layer to the Yocto build system

A preferred method for adding recipes to the build environment, and the method shown with this guide, is to place them within a new layer.

Layers isolate particular sets of build meta-data based on machine, functionality or similar, and help to keep the environment clean.

The meta-mono layer contains Mono specific recipes to support execution of .NET applications on target boards. The layer can be found here.

To use a new layer such as this you first clone the layer from its git repository and then add the layer to your bitbake configuration by editing conf/bblayers.conf

 $ cd ~/yocto/poky-daisy-11.0.0
 $ git clone git://git.yoctoproject.org/meta-mono
 $ cd ~/yocto/poky-daisy-11.0.0/build_qemux86
 $ nano conf/bblayers.conf

Your bblayers.conf should look similar to this

 # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
 # changes incompatibly
 LCONF_VERSION = "6"
 
 BBPATH = "${TOPDIR}"
 BBFILES ?= ""
 
 BBLAYERS ?= " \
   /home/user/yocto/poky-daisy-11.0.0/meta \
   /home/user/yocto/poky-daisy-11.0.0/meta-yocto \
   /home/user/yocto/poky-daisy-11.0.0/meta-yocto-bsp \
   "
 BBLAYERS_NON_REMOVABLE ?= " \
   /home/user/yocto/poky-daisy-11.0.0/meta \
   /home/user/yocto/poky-daisy-11.0.0/meta-yocto \
   "

Make the new layer visible to bitbake by adding a line to BBLAYERS

 BBLAYERS ?= " \
   /home/user/yocto/poky-daisy-11.0.0/meta \
   /home/user/yocto/poky-daisy-11.0.0/meta-yocto \
   /home/user/yocto/poky-daisy-11.0.0/meta-yocto-bsp \
   /home/user/yocto/poky-daisy-11.0.0/meta-mono \
   "

Now bitbake can see the recipes in the new layer.

You will also see when bitbake runs and shows the Build Configuration that the repository branch and hash of your layer is shown which is useful to know, particularly when comparing notes with others as to why a build fails, e.g.

 Build Configuration:
 BB_VERSION        = "1.22.0"
 BUILD_SYS         = "i686-linux"
 NATIVELSBSTRING   = "Ubuntu-12.04"
 TARGET_SYS        = "i586-poky-linux"
 MACHINE           = "qemux86"
 DISTRO            = "poky"
 DISTRO_VERSION    = "1.6"
 TUNE_FEATURES     = "m32 i586"
 TARGET_FPU        = ""
 meta
 meta-yocto
 meta-yocto-bsp    = "<unknown>:<unknown>"
 meta-mono         = "master:cb4998b3fbb7912468df8fc06d692fa872a21947"

Build an image including Mono/.NET support

The meta-mono layer includes a recipe to build an image core-image-mono based on the Yocto standard image core-image-sato

To build this image

 $ bitbake core-image-mono

This may take a while, even if you have already built core-image-minimal as additional GUI support packages need to be built.

The core-image-mono recipe can be found here and pulls in an include file from here.

You can see in the include file that extra packages are added to the standard core-image-sato image.

 IMAGE_INSTALL += "libgdiplus mono mono-helloworld"
 

This is how you would add Mono support to your image within a recipe, or within a .bbappend file. In fact it should only be necessary to add the mono package as this has a dependency on libgdiplus and it is not necessary to have the examples unless you wish to for testing purposes.

The mono-helloworld recipe included here shows how to build the example project using autotools. For details see the recipe itself here, and more importantly the include file it pulls in here.

You could choose to replace mono-helloworld with mono-helloworld-xbuild which as the name suggests shows how to build the eaxmple project with xbuild.

Testing the .NET executable on an emulated target

Having built core-image-mono you can then run it up under qemu

To run up the image, simply use

$ runqemu qemux86

This will boot the emulator, load up the image, you'll see a kernel loading and then a basic user interface.

If you find that your keymap is incorrect you might wish to set this explicitly, for example

$ runqemu qemux86 qemuparams='-k en-gb'

or

$ runqemu qemux86 qemuparams='-k en-us'

Open up a terminal window using the appropriate icon, Log into the emulator as 'root', no password and run the examples.

You can run the first with

 $ mono helloworld.exe

Or alternatively the recipe installs a script to wrap use of Mono, so you can use the form

 $ helloworld

This will output

HelloWorld

You can run the second with

 $ mono ??? helloworldform.exe

or

 $ helloworldform

Depending on your host environment (e.g. using SSH) you may need to explicitly set the DISPLAY variable for this to work, with

 $ export DISPLAY=:0
 $ mono ??? helloworldform.exe

This will show a test Windows Forms form titled 'Hello World'

???

Breakdown of an autotools recipe

TBD

Breakdown of an xbuild recipe

TBD

Feedback

This is a living document. Please feel free to send comments, questions, corrections to Alex Lennon here