Difference between revisions of "BuildingImage"
(→Problems with No GNU_HASH fount in elf) |
(→Problems with No GNU_HASH fount in elf) |
||
Line 69: | Line 69: | ||
Then the same problem emerged in the pxaregs recipes and the same solution applied. This resulted in a completed bake. | Then the same problem emerged in the pxaregs recipes and the same solution applied. This resulted in a completed bake. | ||
− | == | + | ==undefined reference to `__aeabi_uldivmod' in utsname_sysctl.c == |
In Omap kernel the problem has been solved. Copy the patch from there like so. | In Omap kernel the problem has been solved. Copy the patch from there like so. | ||
More info from [http://bugs.openembedded.net/show_bug.cgi?id=4333| here] | More info from [http://bugs.openembedded.net/show_bug.cgi?id=4333| here] |
Revision as of 15:38, 16 May 2009
Contents
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, I copied the Verdex image recipes to the user.collection.
mkdir -p ~/overo-oe/user.collection/images/ cp ~/gumstix/gumstix-oe/com.gumstix.collection/packages/images/* ~/overo-oe/user.collection/images/
Once copied, I ran:
bitbake gumstix-basic-image
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
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).
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. This resulted in a completed bake.
undefined reference to `__aeabi_uldivmod' in utsname_sysctl.c
In Omap kernel the problem has been solved. Copy the patch from there like so. More info from here