Difference between revisions of "BuildingImage"
(→Failing build when building the java development) |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | =NOT YET BUILDING A WORKING KERNEL AND IMAGE THIS WAY= | ||
+ | This page describes efforts so far to build gumstix kernel and X11 image with java support using the the overo-oe repository instead of gumstix-oe. However, this does not yet produce a working kernel and image. You have been warned! | ||
+ | |||
==My Build system== | ==My Build system== | ||
I am running a VM-ware player image with Gentoo Linux placed on a USB hostpowered disc. This does not give highest possible performance, but it allows for a lot of mobility and portability. Peripherals like a (micro)SD-card reader adapter for USB works fine, but the built-in one in my laptop is not available within the VM-ware player. | I am running a VM-ware player image with Gentoo Linux placed on a USB hostpowered disc. This does not give highest possible performance, but it allows for a lot of mobility and portability. Peripherals like a (micro)SD-card reader adapter for USB works fine, but the built-in one in my laptop is not available within the VM-ware player. | ||
Line 5: | Line 8: | ||
The reason for choosing the open-embedded as for Overo is that the Verdex buildsystem has not been updated for approx. a year now and I wanted the latest recipes to get e.g. Open JDK. | The reason for choosing the open-embedded as for Overo is that the Verdex buildsystem has not been updated for approx. a year now and I wanted the latest recipes to get e.g. Open JDK. | ||
− | |||
− | |||
== Building an Rootfs image and a kernel== | == Building an Rootfs image and a kernel== | ||
Line 14: | Line 15: | ||
~/overo-oe/ | ~/overo-oe/ | ||
− | Then, make sure that the machine selected is gumstix- | + | Then, make sure that the machine selected is gumstix-custom-verdex. The machine is defined in the file ~/overo-oe/build/conf/auto.conf. Change it to be: |
− | + | ||
− | + | MACHINE = "gumstix-custom-verdex" | |
− | + | Then, I copied the Verdex image recipes to the user.collection. First, make the directory. | |
− | + | mkdir -p ~/overo-oe/user.collection/images/linux | |
− | Then, I copied the Verdex image recipes to the user.collection. | + | cd ~/overo-oe/user.collection/images/linux/ |
− | mkdir -p ~/overo-oe/user.collection/images/ | + | cp -r ~/gumstix/gumstix-oe/com.gumstix.collection/packages/images/linux/gumstix* . |
− | cp ~/gumstix/gumstix-oe/com.gumstix.collection/packages/images/ | + | Make sure you copied recipes for 2.6.21, 2.6.24, directories with content for gumstix-kernel-* and the gumstix-kernel.inc. |
Once copied, I ran: | Once copied, I ran: | ||
− | bitbake gumstix- | + | bitbake gumstix-kernel |
Resulting in a failure and Bitbake reporting that nothing provides some package and exited without building anything. I then copied the recipes for those packages and ran bitbake again. At the end I had copied: | Resulting in a failure and Bitbake reporting that nothing provides some package and exited without building anything. I then copied the recipes for those packages and ran bitbake again. At the end I had copied: | ||
Line 35: | Line 35: | ||
www-content | www-content | ||
+ | |||
+ | |||
+ | === The following is a false path that makes the build go OK, but is lilkely to produce corrupted images/kernel. | ||
===Gumstix-kernel and sumversion.c === | ===Gumstix-kernel and sumversion.c === | ||
Line 91: | Line 94: | ||
==undefined reference to `__aeabi_uldivmod' in utsname_sysctl.c == | ==undefined reference to `__aeabi_uldivmod' in utsname_sysctl.c == | ||
− | + | This seems to be related to the gcc version that fails. The following version works for gumstix-oe, so we go for that. | |
− | + | PREFERRED_VERSION_gcc-cross = "4.1.2" | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
Latest revision as of 09:30, 21 July 2009
Contents
- 1 NOT YET BUILDING A WORKING KERNEL AND IMAGE THIS WAY
- 1.1 My Build system
- 1.2 Building an Rootfs image and a kernel
- 1.3 Problems with No GNU_HASH fount in elf
- 1.4 undefined reference to `__aeabi_uldivmod' in utsname_sysctl.c
- 1.5 ERROR: Exception:<type 'exceptions.TypeError'> Message:do_split_packages() got an unexpected keyword argument 'allow_links'
- 1.6 Failing build when building the java development
NOT YET BUILDING A WORKING KERNEL AND IMAGE THIS WAY
This page describes efforts so far to build gumstix kernel and X11 image with java support using the the overo-oe repository instead of gumstix-oe. However, this does not yet produce a working kernel and image. You have been warned!
My Build system
I am running a VM-ware player image with Gentoo Linux placed on a USB hostpowered disc. This does not give highest possible performance, but it allows for a lot of mobility and portability. Peripherals like a (micro)SD-card reader adapter for USB works fine, but the built-in one in my laptop is not available within the VM-ware player.
On my Gentoo linux I set-up the build environment according to the instructions for the overo build system.
The reason for choosing the open-embedded as for Overo is that the Verdex buildsystem has not been updated for approx. a year now and I wanted the latest recipes to get e.g. Open JDK.
Building an Rootfs image and a kernel
First I checked out a copy of (instructions) the Verdex build system. So the home directory now has:
~/gumstix/gusmtix-oe/ ~/overo-oe/
Then, make sure that the machine selected is gumstix-custom-verdex. The machine is defined in the file ~/overo-oe/build/conf/auto.conf. Change it to be:
MACHINE = "gumstix-custom-verdex"
Then, I copied the Verdex image recipes to the user.collection. First, make the directory.
mkdir -p ~/overo-oe/user.collection/images/linux cd ~/overo-oe/user.collection/images/linux/ cp -r ~/gumstix/gumstix-oe/com.gumstix.collection/packages/images/linux/gumstix* .
Make sure you copied recipes for 2.6.21, 2.6.24, directories with content for gumstix-kernel-* and the gumstix-kernel.inc.
Once copied, I ran:
bitbake gumstix-kernel
Resulting in a failure and Bitbake reporting that nothing provides some package and exited without building anything. I then copied the recipes for those packages and ran bitbake again. At the end I had copied:
task-base-gumstix motd uisp version www-content
=== The following is a false path that makes the build go OK, but is lilkely to produce corrupted images/kernel.
Gumstix-kernel and sumversion.c
The Gumstix-kernel recipe fails with the error message
warning: unused variable 'filelist'
The problem can be solved by adding '#include <limits.h>' after strings.h in scripts/mod/sumversion.c fixes the issue. The file is found at: ~/overo-oe/tmp/work/gumstix-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21-r0/linux-2.6.21/scripts/mod/sumversion.c
#include <netinet/in.h> #ifdef __sun__ #include <inttypes.h> #else #include <stdint.h> #endif #include <ctype.h> #include <errno.h> #include <string.h> #include <limits.h> <--- add this line #include "modpost.h" /* * Stolen form Cryptographic API. * * MD4 Message Digest Algorithm (RFC1320).
Or by copying a patch from
# cd ~/overo-oe/org.openembedded.dev/recipes/linux # cp files/linux-2.6-limits.patch gumstix-kernel-2.6.21/
In the gumstix-kernel_2.6.21.bb add to the list of files in SRC_URI the following line:
file://linux-2.6-limits.patch;patch=1 \
In the patch, change the filename to be:
--- linux-2.6.21/scripts/mod/sumversion.c.orig 2009-03-15 21:44:58.000000000 +0100 +++ linux-2.6.21/scripts/mod/sumversion.c 2009-03-15 21:44:58.000000000 +0100
Problems with No GNU_HASH fount in elf
Baking the gumstix-basic-image the process stopped with the I2C package and the log information boiled down to the error message: No GNU_HASH fount in elf for the i2c.
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/<user>/overo-oe/tmp/work/armv5te-angstrom-linux-gnueabi/i2c-1.0-r2/install/i2c/usr/bin/i2c'
Asking for hints in the gumstix.users mailing list helped alot. Thanks Koen and Philip (archive here) and I could find the problem in the i2c.bb file: The task do_compile ignored the LDFLAGS set by the oe/autoconf tools.
do_compile () { ${CC} -o i2c *.c }
Adding ${LDFLAGS} to the line for compiling solved this problem:
do_compile () { ${CC} -o i2c *.c ${LDFLAGS} }
Then the same problem emerged in the pxaregs recipes and the same solution applied.
undefined reference to `__aeabi_uldivmod' in utsname_sysctl.c
This seems to be related to the gcc version that fails. The following version works for gumstix-oe, so we go for that. PREFERRED_VERSION_gcc-cross = "4.1.2"
ERROR: Exception:<type 'exceptions.TypeError'> Message:do_split_packages() got an unexpected keyword argument 'allow_links'
My solution to this was to edit the recipe angstrom-feed-config.bb and remove the allow_links=True from the do_split_packages() method call at the end, from:
do_split_packages(d, etcdir, '^locale-(.*)\.conf$', 'angstrom-locale-%s-config', 'Angstrom feed config for the %s locale', extra_depends=, allow_links=True)
to:
do_split_packages(d, etcdir, '^locale-(.*)\.conf$', 'angstrom-locale-%s-config', 'Angstrom feed config for the %s locale', extra_depends=)
Find out another solution here the problem here
Failing build when building the java development
Firts make sure you follow the instructions fo Java on the Openembedde wiki. Found here
I used this and still had probles related to native antlr. The simple solution for me was to make sure that Antlr was part of my Gentoo linux by:
emerge antlr
Removing the tmp/work dir and then rebuilding fixed the problem. The intention seems to be to have self contained java environment in open embedded but antlr and antrl-native recipes seems to have a cyclic dependancy so bitbaking these results in the same problem.