Talk:MokoMakefile

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Neither MokoMakefile (nor FSO-makefile) work on Intrepid amd64)
(Solution)
Line 33: Line 33:
 
:I get the same error on Intrepid i386. Any solutions? --[[User:Cgerum|Cgerum]] 13:46, 28 October 2008 (UTC)
 
:I get the same error on Intrepid i386. Any solutions? --[[User:Cgerum|Cgerum]] 13:46, 28 October 2008 (UTC)
  
== Solution ==
+
=== Solution ===
 
i get this error on Intrepid i386. To solve this only change file build/conf/local.conf
 
i get this error on Intrepid i386. To solve this only change file build/conf/local.conf
 
<pre>
 
<pre>

Revision as of 17:03, 10 December 2008

Contents

Neither MokoMakefile (nor FSO-makefile) work on Intrepid amd64

When trying to build the toolchain many packages (gcc 3, gcc 4, qemu...) will fail to build. Except from qemu, most are because variations of the following error:

/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments

As, for instance, in libxml2:

| nanohttp.c: In function 'xmlNanoHTTPFetch__internal_alias':
| nanohttp.c:1558: warning: ignoring return value of 'write', declared with attribute warn_unused_result
| nanohttp.c: In function 'xmlNanoHTTPSave__internal_alias':
| nanohttp.c:1597: warning: ignoring return value of 'write', declared with attribute warn_unused_result
| In function 'open',
|     inlined from 'xmlNanoHTTPSave__internal_alias' at nanohttp.c:1588:
| /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
| make[2]: *** [nanohttp.lo] Error 1
| make[2]: Leaving directory `/home/jisakiel/openmoko/build/tmp/work/x86_64-linux/libxml2-native-2.6.29-r3/libxml2-2.6.29'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/jisakiel/openmoko/build/tmp/work/x86_64-linux/libxml2-native-2.6.29-r3/libxml2-2.6.29'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed: /home/jisakiel/openmoko/build/tmp/work/x86_64-linux/libxml2-native-2.6.29-r3/temp/log.do_compile.24092
NOTE: package libxml2-native-2.6.29-r3: task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package libxml2-native-2.6.29: failed

I believe it must be related to D_FORTIFY_SOURCE enabled by default (see: https://wiki.ubuntu.com/CompilerFlags ). However I cannot get to work.

I tried editing build/conf/local.conf and adding TARGET_CFLAGS="-D_FORTIFY_SOURCE=0" there (as well as ASSUME_PROVIDED += "gcc3-native" to keep building), with no success at all.

System is intrepid on amd64.

I get the same error on Intrepid i386. Any solutions? --Cgerum 13:46, 28 October 2008 (UTC)

Solution

i get this error on Intrepid i386. To solve this only change file build/conf/local.conf

 $ cat build/conf/local.conf 
 MACHINE = "om-gta02"
 DISTRO = "openmoko"
 BUILD_ARCH = "i386"
 INHERIT += "rm_work"
 TARGET_CFLAGS="-D_FORTIFY_SOURCE=0 -O2"
 TARGET_CPPFLAGS="-D_FORTIFY_SOURCE=0 -O2"

i added -D_FORTIFY_SOURCE=0, -O2 and change BUILD_ARCH to i386. I don't know if all changes are neccesary. --Javisantana 16:02, 10 December 2008 (UTC)


Workaround

I installed a debian sid chroot following the instructions on https://wiki.ubuntu.com/DebootstrapChroot . compilation did not finish yet, but seems to work. --Cgerum 16:16, 2 November 2008 (UTC)

MokoMakefile won't work on Ubuntu Hardy Heron

Hello, there!

Since my upgrade to Hardy Heron MokoMakefile seems to be broken on my ubuntu box. I already tried several times to download a new Makefile into a fresh directory - without success. What I get is always:

~/moko$ make image

( cd build && . ../setup-env && \ ( bitbake openmoko-devel-image u-boot-openmoko ) ) ERROR: Openembedded's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories:

/proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root).

make: *** [openmoko-devel-image] Error 1

For another report on this problem see also: http://lists.openmoko.org/pipermail/community/2008-May/017545.html

When trying to compile the april software update (ASU) this error doesn't occour, though.

solution

$ sudo vim /etc/sysctl.conf

Change vm.mmap_min_addr = 65536 to vm.mmap_min_addr = 0

OR

$ sudo sysctl -w vm.mmap_min_addr=0

Another solution consist to run these commands: (This one worked for me, not the first)

echo 0|sudo tee /proc/sys/vm/mmap_min_addr

OR

su root
echo 0 > /proc/sys/vm/mmap_min_addr
exit

Obviously, it's doing the same thing.

(Solutions found here: http://lists.openmoko.org/nabble.html#nabble-td759686 and here: http://lists.openmoko.org/nabble.html#nabble-td778718)

Finally, the best and recommended solution (as of Intrepid) would be to add that line ( vm.mmap_min_addr = 0 ) to a standalone file (named as one might wish, for instance 60-mmap-mokomakefile-fix) on /etc/sysctl.d/ .

The paths that are mentioned on this page are partially wrong

I am not sure enough what the paths should be, but - two things have changed since the section "developing with mokomakefile/How to add your own shiny new application" of this page was created: - The path where the packages are kept, and - Where to add the information that we have added a new package.

Update git to 1.5!

Version git-1.4 does not work, check your version with the command

git --version

and install at least git version 1.5 if not already present.

Fails on a 32bit machine - try again without ccache?

/bin/sh ./libtool --mode=compile     ccache     gcc -DHAVE_CONFIG_H -I.... -W... -O2 -c -o libbfd.lo build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c
ccache gcc -DHAVE_CONFIG_H -I... -W... -O2 -c  /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c -o   t shift count >= width of type
make[5]: *** [libbfd.lo] Error 1

Any insight here? --Adam 23:10, 15 May 2007 (CEST)

Try without ccache (did you get it compiled meanwhile or can we remove this?) --BernhardKaindl 23:05, 19 September 2007 (CEST)

Facing Problems with ogg libraries

just get the path and delete the .bb file that causes the problem

Building on Fedora Core 6

Install stuff needed for OpenMoko:

  1. yum install python m4 make wget curl ftp cvs monotone 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 compat-gcc-34 lynx netpbm (notice compat-gcc-34 wich was needed for FC6 (gcc 4 installed), and lynx which is needed by qemu (no fallback to wget, curl, or links at the moment and no check for it, resulting in strange "sleep" errors when trying to build without lynx).

Build it: $ make setup $ make openmoko-devel-image $ unset LD_LIBRARY_PATH $ make update-makefile && make update && make setup && make openmoko-devel-image

I have also done a $ unset LD_LIBRARY_PATH; make update-makefile && nice make update && nice make setup && nice make all (This takes several hours)

Build qemu: $ make qemu

Run it:

  1. echo 1024 > /proc/sys/dev/rtc/max-user-freq

$ make run-qemu This will bring up the OpenMoko :) Use SPACE for AUX and ENTER for POWER. Not quite the same as holding a Neo1973 in your hands I would guess, but this is the best we can do for now. Thanks!

Building on Ubuntu Feisty

MokoMakefile requires more than 512 MB of RAM + Swap space (around 1GB?).

If you need swap, please check that its size under Feisty is not null!

Bug #105490 describes the current issue and offers a workaround (23 Jul 07).

Fails trying to build bluez-utils

on Gentoo Linux, it fails compiling bluez-utils (I've tried also "make clean-package-bluez-utils" before the following command)

do a "make build-package-libusb; make clean-package-bluez-utils" and it should continue (the bluez-utils .bb is missing the libusb dependency)

openSUSE 10.1 and 10.2 workarounds

ltrace package fails to build with error:

...
checking for pid_t... yes
checking for getopt... yes
checking for getopt_long... yes
checking gelf.h usability... no
checking gelf.h presence... no
checking for gelf.h... no
configure: error: ***** gelf.h not found *****
FATAL: oe_runconf failed

FIX: edit /home/moko/build/tmp/work/armv4t-linux/ltrace-0.4-r0/ltrace-0.4/configure.ac at line 44: remove the following block:

for path in /usr/include/elfutils /usr/local/include/elfutils \
/usr/include/libelf /usr/local/include/libelf; do
if test -f ${path}/gelf.h; then
CPPFLAGS="$CPPFLAGS -I ${path}"
fi
done

( it adds /usr/include/elfutils to path, which causes cross-compile badness error )

QEMU build fails to compile USB code

/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_control':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:103: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_data':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: error: storage size of 'bt' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:132: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: warning: unused variable `bt'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_device_open':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: error: storage size of 'ctrl' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:202: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: warning: unused variable `ctrl'
make[2]: *** [usb-linux.o] Error 1

FIX: edit /home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c at line 29 add the following (before #include <linux/usbdevice_fs.h>)

#include <linux/compiler.h>

hint: there is a copy of the file in /home/moko/build/tmp/work/i686-linux/qemu-native-0.9.0+cvs20070613-r5/qemu/usb-linux.c

see: http://osdir.com/ml/emulators.kvm.devel/2007-01/msg00101.html

Cannot satisfy fstests

make openmoko-devel-image
...
| Collected errors:
| ERROR: Cannot satisfy the following dependencies for task-openmoko-debug:
|        fstests
NOTE: Task failed: /no-backup/Moko/build/tmp/work/fic-gta01-linux/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.25036
NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting

Failed on debian etch 2007-07-20 Solution from mailing list post from hardskinone, report of an irc chat

I got help in IRC channel. I do following steps
* remove fstest from oe/packages/tasks/task-openmoko.bb ,
* increase PR field by one
* make openmoko-devel-image

conflicting types for 'futimens'

if you encounter the following error:


| In file included from utimecmp.c:40: | utimens.h:2: error: conflicting types for 'futimens' | /usr/include/sys/stat.h:370: error: previous declaration of 'futimens' was here

a patch is needed because your glibc is too new. grab & enable the patch as follows

cd openembedded/packages/coreutils mv coreutils_5.3.0.bb coreutils_5.3.0.orig wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils_5.3.0.bb cd - cd openembedded/packages/coreutils/coreutils-5.3.0 wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils-5.3.0/futimens.patch cd -

Workaround for problems compiling mtd-utils

Change the line on openembedded/packages/mtd/mtd-utils_1.0.0+git.bb which reads:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=master \

to:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=a6fa706fe9e7696b4b2045edf9698c3bac07e3e3 \

which forces the recipe to use an older revision (the one which worked last time I built the image on my computer).

Be sure to remember to undo the change later, or else you will not get any new changes to that package. --CesarB 04:48, 25 July 2007 (CEST)

Note: these patches should be updated - the lzo patch is included in the current version, so backing off to the previous version and repatching seems silly. I was able to make it through this part of the build by applying the remaining patches manually. --Ted Lemon 15:44, 29 July 2007 (CDT)

Monotone segfaulting on Ubuntu Feisty Fawn/PPC

If you are running Ubuntu Feisty Fawn on a PowerPC computer you will experience problems running monotone. To fix this issue you need to install monotone as well as the libboost packages from Gutsy. The easiest way to accomplish this is to add the gutsy repositories to your sources.list and change the preferences to look like this:

Package: * Pin: release a=feisty Pin-Priority: 700

Package: * Pin: release a=gutsy Pin-Priority: -100

Package: libc6 libc6-dev tzdata util-linux libgcc1 libstdc++6 monotone Pin: release a=gutsy Pin-Priority: 800

Package: libboost-* Pin: release a=gutsy Pin-Priority: 800

After doing this install monotone in this way: apt-get -t gutsy install monotone. That should install monotone 0.35 with updated (and working) boost libraries.


Fails on ncurses install in Fedora 7 with a "tic -x" message

Adjust the following command to your system, then run it: export LD_LIBRARY_PATH=/home/moko/build/tmp/work/x86_64-linux/ncurses-native-5.4-r8/ncurses-5.4/lib Then start make again and it should pick up where it left off.

You can get a list of potential paths to use with the following command from you main moko directory: find . | grep libncurses

The basic problem is that it is linking against your main system libraries instead of the OpenEmbedded ones.

There's probably a cleaner way of handling this - please update this entry if you know it.

This has been fixed in Openembedded, see Openembedded Bug #2554 for further details.

uboot-gta01 fails to build

Changes in the GIT of U-Boot make the OpenMoko patches unapplyable. For the use of Revision cc3023b9f95d7ac959a764471a65001062aecf41 and everything will be fine for now.

Perl fails to build

After following every bit of advice I can find to 'make clean' and nuke the perl build directories, every build comes up with:

| make[1]: Entering directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7' | make[1]: *** No rule to make target `<command-line>', needed by `miniperlmain.o'. Stop. | make[1]: Leaving directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7' | FATAL: oe_runmake failed NOTE: Task failed: /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/temp/log.do_compile.19531 NOTE: package perl-native-5.8.7-r3: task do_compile: failed

Solution turned out to be editing /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7/makedepend.SH and at line 169 change the regexp to eat references to "<command.line>" to catch what was leaking through.

glibc fails to build

If you see an error like


NOTE: package glibc-2.6.1: started
NOTE: package glibc-2.6.1-r10: task do_configure: started
ERROR: function do_configure failed
ERROR: log data follows (/home/alex/moko/build/tmp/work/armv4t-angstrom-linux-gn
ueabi/glibc-2.6.1-r10/temp/log.do_configure.11446)
| NOTE: Running /home/alex/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/gli
bc-2.6.1-r10/glibc-2.6.1/configure                  --build=i686-linux
--host=arm-angstrom-linux-gnueabi                --target=arm-angstrom-linux-
gnueabi                     --prefix=/usr                   --exec_prefix=/usr
--bindir=/usr/bin                --sbindir=/usr/sbin                     --li
bexecdir=/usr/libexec               --datadir=/usr/share                    --sy
sconfdir=/etc               --sharedstatedir=/usr/com               --localstate
dir=/var                    --libdir=/usr/lib               --includedir=/usr/in
clude               --oldincludedir=/usr/include                    --infodir=/u
sr/share/info               --mandir=/usr/share/man                       --enab
le-kernel=2.4.0   --without-cvs --disable-profile --disable-debug --without-gd
--enable-clocale=gnu   --enable-add-ons=ports,nptl,libidn   --with-headers=/hom
e/alex/moko/build/tmp/staging/arm-angstrom-linux-gnueabi/usr/include   --without
-selinux     --without-fp --without-fp              ...
| configure: loading site script /home/alex/moko/openembedded/site/endian-little
| configure: loading site script /home/alex/moko/openembedded/site/common-linux
| configure: loading site script /home/alex/moko/openembedded/site/common-glibc
| configure: loading site script /home/alex/moko/openembedded/site/arm-common
| configure: loading site script /home/alex/moko/openembedded/site/arm-linux
| configure: loading site script /home/alex/moko/openembedded/site/common
| configure: loading site script /home/alex/moko/openembedded/site/common
| checking build system type... i686-pc-linux-gnu
| checking host system type... arm-angstrom-linux-gnueabi
| checking add-on ports for preconfigure fragments... am33 arm hppa m68k mips
| configure: running configure fragment for add-on nptl
| configure: running configure fragment for add-on libidn
| checking sysdep dirs... ports/sysdeps/arm/elf ports/sysdeps/unix/sysv/linux/ar
m/eabi/nptl ports/sysdeps/unix/sysv/linux/arm/eabi sysdeps/unix/sysv/linux/arm/e
abi ports/sysdeps/unix/sysv/linux/arm/nptl ports/sysdeps/unix/sysv/linux/arm sys
deps/unix/sysv/linux/arm ports/sysdeps/unix/sysv/linux nptl/sysdeps/unix/sysv/li
nux nptl/sysdeps/pthread sysdeps/pthread sysdeps/unix/sysv/linux sysdeps/gnu sys
deps/unix/common sysdeps/unix/mman sysdeps/unix/inet ports/sysdeps/unix/sysv npt
l/sysdeps/unix/sysv sysdeps/unix/sysv ports/sysdeps/unix/arm ports/sysdeps/unix
nptl/sysdeps/unix sysdeps/unix sysdeps/posix ports/sysdeps/arm/eabi ports/sysdep
s/arm/nptl ports/sysdeps/arm sysdeps/wordsize-32 sysdeps/ieee754/flt-32 sysdeps/
ieee754/dbl-64 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic
| checking for a BSD-compatible install... /home/alex/moko/build/tmp/staging/i68
6-linux/usr/bin/install -c
| checking whether ln -s works... yes
| checking for arm-angstrom-linux-gnueabi-gcc... arm-angstrom-linux-gnueabi-gcc
-march=armv4t -mtune=arm920t
| checking for suffix of object files... o
| checking whether we are using the GNU C compiler... yes
| checking whether arm-angstrom-linux-gnueabi-gcc -march=armv4t -mtune=arm920t a
ccepts -g... yes
| checking for arm-angstrom-linux-gnueabi-gcc -march=armv4t -mtune=arm920t optio
n to accept ANSI C... none needed
| checking for gcc... gcc
| checking how to run the C preprocessor... arm-angstrom-linux-gnueabi-gcc -E
| configure: error: C preprocessor "arm-angstrom-linux-gnueabi-gcc -E" fails san
ity check
| See `config.log' for more details.
| FATAL: oe_runconf failed
NOTE: Task failed: /home/alex/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-2.6.1-r10/temp/log.do_configure.11446
NOTE: package glibc-2.6.1-r10: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package glibc-2.6.1: failed
ERROR: Build of /home/alex/moko/openembedded/packages/glibc/glibc_2.6.1.bb do_co
nfigure failed
ERROR: Task 7 (/home/alex/moko/openembedded/packages/glibc/glibc_2.6.1.bb, do_co
nfigure) failed
NOTE: Tasks Summary: Attempted 448 tasks of which 440 didn't need to be rerun an
d 1 failed.
ERROR: '/home/alex/moko/openembedded/packages/glibc/glibc_2.6.1.bb' failed
NOTE: build 200808041052: completed

Try

cd source rm glibc*2.6.1* cd ../build . ../setup-env bitbake -crebuild glibc

if this doesn't help, you have to do this

cd build . ../setup-env bitbake -f -c fetch gcc-cross-initial && bitbake gcc-cross-initial && bitbake -crebuild glibc

Gettext fails to build

Gettext's build is broken unless you have emacs installed. Crazy though it seems. You will see an error like:


| WARNING: Warnings can be ignored. :-)
| if test "no" != no; then \
|         set x; \
|         list='po-mode.el po-compat.el'; for p in $list; do \
|           if test -f "$p"; then d=; else d="./"; fi; \
|           set x "$@" "$d$p"; shift; \
|         done; \
|         shift; \
|         EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| if test "no" != no; then \
|         set x; \
|         list='po-mode.el po-compat.el'; for p in $list; do \
|           if test -f "$p"; then d=; else d="./"; fi; \
|           set x "$@" "$d$p"; shift; \
|         done; \
|         shift; \
|         EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
|       else : ; fi
| mv: cannot move `elc-temp' to `elc-stamp': No such file or directory
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[5]: *** [elc-stamp] Error 1
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[4]: *** [po-mode.elc] Error 2
| make[4]: *** Waiting for unfinished jobs....
| make[4]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1'
| FATAL: oe_runmake failed

The solution is simple - install emacs (example below for debian/ubuntu) and try again:


sudo apt-get install emacs
make clean-package-gettext-native-0.14.1-r5
make openmoko-devel-image

Building OpenMoko with chroot

There may be hundreds of issues which may cause that OpenMoko fails to build on your system, so it might be more straightforward to just install a standardized build environment in which the openmoko build runs in chroot, independent of your distribution.

There is now a (not fully working) script which is able to set up a 32-bit openSUSE 10.3 build environment for building OpenMoko posted on distro-devel: [1]

On gentoo and debian-like distribution, you can use debootstrap to quickly setup a base chroot.

Please note that in addition to the common /dev, /sys and /proc, /dev/shm should also be mounted with --bind option. It is at least required to build a qtopia-x11 image. (Otherwise you will get some semaphore 'function not implemented' errors at qtopia-x11 installation stage).

Fails compiling binutils-cross on Gentoo/AMD64 and openSUSE/x86_64

make setup works fine, but when running make openmoko-devel-image it fails with the following:

| make[4]: Entering directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[4]: Nothing to be done for `install'.
| make[4]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[3]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty'
| make[2]: Nothing to be done for `install-target'.
| make[2]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| make[1]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib/gcc-lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross: No such file or directory
| mv: cannot stat `build/tmp/cross/lib/libiberty.a': No such file or directory
NOTE: Task failed: build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/temp/log.do_stage.9730
NOTE: package binutils-cross-2.18-r0: task do_populate_staging: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of openembedded/packages/binutils/binutils-cross_2.18.bb do_populate_staging failed
ERROR: Task 1641 (openembedded/packages/binutils/binutils-cross_2.18.bb, do_populate_staging) failed
NOTE: Tasks Summary: Attempted 107 tasks of which 107 didn't need to be rerun and 1 failed.
ERROR: 'openembedded/packages/binutils/binutils-cross_2.18.bb' failed
make: *** [openmoko-devel-image] Error 1

The final reason why the build cannot continue is: mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

The lib64 issue

Likely, Gentoo/AMD64 uses lib64 instead of lib as the library directory for x86_64 libraries. It's l likey that many (or all?) AMD64 distributions do for their 64-bit binaries. On openSUSE-x86_64, the same happens. Debian/x86-64 seems to either not use lib64 or is somehow supported by the openmoko distribution.

On multilib/lib64 platforms like Gentoo/x86_64 and openSUSE-x86_64, the openmoko build runs into a final problem at the end of build: It tries to use fakeroot which uses LD_PRELOAD to fake a different root directory and in the final stages, after hours of compiling, fakeroot execution causes warning messages because on multilib/lib64 systems as they have two versions of many libraries, the 64-bit libraries are in /lib64, /usr/lib64 and oder lib64 paths, while the 32-bit libraries are in /lib, /usr/lib and other lib paths. Some tool on these lib64 distributions are adapted to install 64-bit libraries to lib64, but this seems to fail when cross-compiling.

At least on openSUSE-10.3 the missing libiberty.a was installed to build/tmp/cross/lib64/libiberty.a, which looks wrong, and it is if this libiberty.a file contains 32-bit arm objects. If it contains 64-bit x86_64 objects, it's fine, but openembedded/openmoko is not expecting it in a lib64 directory. I am not sure what is the case.

The lib64 fakeroot issue requires to change the openembedded build scripts, which is doable. But it's not very easy to find the correct script and patch it correctly. If you feel adventourus, go ahead and try to build openmoko on a lib64 distribution, but it's easyer to set up a complete 32-bit chroot environment and run a normal build in it.

After seeing this, I assumed that openmoko/openembedded was clearly not tested with lib64 build hosts and since that would mean that even if I'd fix that error, many others could follow, and as I was not interested to fix the lib64 bugs but rather wanted to see something running first, I decided to make openmoko/openembedded think that it was running on a normal 32-bit non-lib64 machine.

There are several ways to do that:

  • You install an 32bit x86-Linux somewhere and use that for building:
    • Do a native install and dual-boot the 32bit x86-linux (That's for dummies which do not know the other tricks)
    • Install 32bit x86-Linux in a virtual machine (Takes powerful hardware and has some overhead too). Use VirtualBox, for example.
  • you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience). See the gentoo guide

Building on SuSE Linux 10.3-AMD64 with -m32 (not finished)

Install the following packages for the 32-bit C/C++ compiler target option -m32 to work and to compile what is needed

gcc42-32bit gcc42libgcc42-32bit glibc-devel-32bit libstdc++-devel-32bit ncurses-devel-32bit zlib-devel-32bit (maybe also gtk2-devel-32bit)

The openSUSE 10.3-AMD64 has no libopenssl-devel-32bit, but you can install the 32-bit rpm from the i586 10.3 rpm tree:

libopenssl-devel

You should also make sure that gdbm-devel is not installed. The multilib support in ld has an issue which surfaces when it is called from perl's Configure script to complile a test program with -Lgdbm. If gdbm-devel is installed, it finds /usr/lib64/libgdbm.so, but since it's not compatible with 32-bit, it skips it, but also does not search the specified -Lpath where the OpenEmbedded-built libgdbm.so is already installed. To work around this, uninstall /usr/lib64/libgdbm.so with: rpm -e gdbm-devel

Note these need to be the 32-bit cpp33 and gcc33 rpms as the 64-bit gcc33 rpms for openSUSE do not support the 32-bit target.

To make the OpenMoko build think that its running on 32-bit i686, use linux32 (changes uname -m to i686 in the new shell):

linux32 bash

And set up gcc scripts which force the use of gcc-3.3 (it can only generate 32-bit assembly) for all compilation:

mkdir bin;cd bin echo '/usr/bin/${0##*/}-3.3 -m32 "$@"' >gcc echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld echo '/usr/bin/${0##*/} --32 "$@"' >gas sed -i '1i#!/bin/sh' gcc gas ld chmod 755 gcc gas ld ln -s gcc cc ln -s gcc c++ ln -s gcc g++ ln -s gas as echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32 cd -

Then set the path and test it:

source bin/.setup-gcc-m32 type gcc

More package requirements

On my system (Kubuntu 6.10) build failed with message "ERROR: QEMU requires SDL or Cocoa for graphical output" because package libsdl-image1.2-dev was missing. Use apt-get install libsdl-image1.2-dev to install. Additionally I had to install packages cvs and diffstat. I was also asked to install Psyco JIT Compiler (package python-psyco) to increase performance. Nevertheless make flash-qemu-local took some hours, but now I finally can get an impression of the phone that I am looking for! -- Nichtich 00:26, 20 September 2007 (CEST)

pango-directfb failed to build due to missing Glib 2.14.x

The latest(as of Sept. 25, 2007) build started to fail with the following error:

| checking for GLIB... no | configure: error: | *** Glib 2.14.0 or better is required. The latest version of | *** Glib is always available from ftp://ftp.gtk.org/. | FATAL: oe_runconf failed NOTE: Task failed: /media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\ pango-directfb-1.18.1-r0/temp/log.do_configure.19927 NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed ERROR: TaskFailed event exception, aborting NOTE: package pango-directfb-1.18.1: failed ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\ pango-directfb_1.18.1.bb do_configure failed

The Glib included in the build tree seems to be only 2.12.12, so looks like something is broken in term of dependency.

This had happened on both of Fedora 7 and Debian Etch. I am running the latest MokoMakefile with OM-2007.2. The funny thing is that the build had worked only couple nights ago. Any idea? I will update anything I find here and also on my blog(see my user profile). ttz Wed Sep 26 12:17:33 CDT 2007

pango-directfb had been removed from OE for now due to the report of it breaking builds like OpenMoko.

ttz Thu Oct 4 10:20:12 CDT 2007

uicmoc4 failes to compile

This is solved by installing libz-dev

Or, look at Bug #747

svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'

osiris$ make update ... Fetching external item into 'trunk/src/target/OM-2007.2/applications/openmoko-today2/libkoto' svn: REPORT request failed on '/repos/tasks/!svn/vcc/default' svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com) make: *** [update-openmoko] Error 1

osiris$ cd openmoko/trunk/src/target/OM-2007.2/applications/openmoko-today2//libkoto/ osiris$ svn up -r HEAD svn: REPORT request failed on '/repos/tasks/!svn/vcc/default' svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)

Anyone know about this one? --Blackh 00:11, 12 October 2007 (CEST)

bootparam_prot.h fails to install in glibc-intermediate-2.5 package (Debian sid)

| install: cannot stat `/home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc/bootparam_prot.h' No such file or directory NOTE: Task failed: /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ glibc-intermediate-2.5-r7/temp/log.do_stage.3940

For some reason, on Debian, the rpcgen command needs "-Y /usr/bin" added to the end of it or it won't work ("cannot find any C preprocessor (cpp)"). This can be fixed by hand...

cd /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc for f in *.x ; do rpcgen -h $f -o ${f%%.x}.h -Y /usr/bin ; done

This command will generate the right files and you can resume the build with

make openmoko-devel-image

Here is a better fix - put this script, calling it rpcgen, somewhere in your PATH before /usr/bin:

  1. !/bin/sh

exec /usr/bin/rpcgen -Y /usr/bin "$@"

--Blackh 05:17, 12 October 2007 (CEST)

Cannot find SVN openmoko-terminal2

I'm having an issue when building MokoMakeFile where it is unable to find http://svn.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-terminal2. Any ideas on how to fix this?

--cartera

problem with make openmoko-devel-image

when i try to do my first make openmoko-devel-image I obtain this error:

NOTE: Running task 844 of 5445 (ID: 671, /home/xraver/moko/openembedded/packages/linux/linux-openmoko_2.6.24+git.bb, do_fetch)
NOTE: package linux-openmoko-2.6.24+git20080422: started
NOTE: package linux-openmoko-1_2.6.24+git20080422-r0: task do_fetch: started
NOTE: fetch http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
--08:47:41--  http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
=> `/home/xraver/moko/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz'
Risoluzione di downloads.openmoko.org in corso... 88.198.93.219
Connessione a downloads.openmoko.org|88.198.93.219:80... connesso.
HTTP richiesta inviata, aspetto la risposta... 404 Not Found
08:47:41 ERRORE 404: Not Found.

In this location http://downloads.openmoko.org/sources/ the file git_git.openmoko.org.git.kernel.git_4194.tar.gz does not exist. Any solutions?

--Giorgio Ravera

they have problems with server, try later. that helped me ...

--bubbas


I have the same error as bubbas... any ideas?

--jas

Wishlist: Make qemu optional

Hi,

I’ve just set up MokoMakefile, and after make setup I tried to get a package with make build-package-openmoko-messages2, but it’s spending a lot of time and disk space on building native libraries and qemu – something that I have not asked for. It would be nice if I could build packages for my phone without having to build unneccessary stuff.

Thanks, Joachim

SVN Certificate issues for Gentoo users

Note for Gentoo users: I think Portage creates a ~/.subversion directory as root if you've ever compiled a svn ebuild via "sudo emerge". If this happens, certificates won't be saved, so you have to take back ownership of the directory:

chown -R $USER ~/.subversion

Before running a svn co from the openmoko svn server to accept the certificate, otherwise the authentication information will not be saved. kelvie 06:05, 18 July 2008 (UTC)

glibc, task do_package_write_ipk: "Package name contains illegal characters"

Package glibc-2.6.1-r11: task do_package_write_ipk may return an error while dealing with locale-base-* packages: Error: Package name contains illegal characters, (other than [a-z0-9.+-]) for no obvious reason. I've found that setting LANG=C (instead of nb_NO.utf8) seems to fix this problem: LANG=C make openmoko-devel-image or export LANG=C make openmoko-devel-image --StianEllingsen 21:44, 28 August 2008 (UTC)

Personal tools

Neither MokoMakefile (nor FSO-makefile) work on Intrepid amd64

When trying to build the toolchain many packages (gcc 3, gcc 4, qemu...) will fail to build. Except from qemu, most are because variations of the following error:

/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments

As, for instance, in libxml2:

| nanohttp.c: In function 'xmlNanoHTTPFetch__internal_alias':
| nanohttp.c:1558: warning: ignoring return value of 'write', declared with attribute warn_unused_result
| nanohttp.c: In function 'xmlNanoHTTPSave__internal_alias':
| nanohttp.c:1597: warning: ignoring return value of 'write', declared with attribute warn_unused_result
| In function 'open',
|     inlined from 'xmlNanoHTTPSave__internal_alias' at nanohttp.c:1588:
| /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
| make[2]: *** [nanohttp.lo] Error 1
| make[2]: Leaving directory `/home/jisakiel/openmoko/build/tmp/work/x86_64-linux/libxml2-native-2.6.29-r3/libxml2-2.6.29'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/jisakiel/openmoko/build/tmp/work/x86_64-linux/libxml2-native-2.6.29-r3/libxml2-2.6.29'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed: /home/jisakiel/openmoko/build/tmp/work/x86_64-linux/libxml2-native-2.6.29-r3/temp/log.do_compile.24092
NOTE: package libxml2-native-2.6.29-r3: task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package libxml2-native-2.6.29: failed

I believe it must be related to D_FORTIFY_SOURCE enabled by default (see: https://wiki.ubuntu.com/CompilerFlags ). However I cannot get to work.

I tried editing build/conf/local.conf and adding TARGET_CFLAGS="-D_FORTIFY_SOURCE=0" there (as well as ASSUME_PROVIDED += "gcc3-native" to keep building), with no success at all.

System is intrepid on amd64.

I get the same error on Intrepid i386. Any solutions? --Cgerum 13:46, 28 October 2008 (UTC)

Solution

i get this error on Intrepid i386. To solve this only change file build/conf/local.conf

 $ cat build/conf/local.conf 
 MACHINE = "om-gta02"
 DISTRO = "openmoko"
 BUILD_ARCH = "i386"
 INHERIT += "rm_work"
 TARGET_CFLAGS="-D_FORTIFY_SOURCE=0 -O2"
 TARGET_CPPFLAGS="-D_FORTIFY_SOURCE=0 -O2"

i added -D_FORTIFY_SOURCE=0, -O2 and change BUILD_ARCH to i386. I don't know if all changes are neccesary. --Javisantana 16:02, 10 December 2008 (UTC)


Workaround

I installed a debian sid chroot following the instructions on https://wiki.ubuntu.com/DebootstrapChroot . compilation did not finish yet, but seems to work. --Cgerum 16:16, 2 November 2008 (UTC)

MokoMakefile won't work on Ubuntu Hardy Heron

Hello, there!

Since my upgrade to Hardy Heron MokoMakefile seems to be broken on my ubuntu box. I already tried several times to download a new Makefile into a fresh directory - without success. What I get is always:

~/moko$ make image

( cd build && . ../setup-env && \ ( bitbake openmoko-devel-image u-boot-openmoko ) ) ERROR: Openembedded's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories:

/proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root).

make: *** [openmoko-devel-image] Error 1

For another report on this problem see also: http://lists.openmoko.org/pipermail/community/2008-May/017545.html

When trying to compile the april software update (ASU) this error doesn't occour, though.

solution

$ sudo vim /etc/sysctl.conf

Change vm.mmap_min_addr = 65536 to vm.mmap_min_addr = 0

OR

$ sudo sysctl -w vm.mmap_min_addr=0

Another solution consist to run these commands: (This one worked for me, not the first)

echo 0|sudo tee /proc/sys/vm/mmap_min_addr

OR

su root
echo 0 > /proc/sys/vm/mmap_min_addr
exit

Obviously, it's doing the same thing.

(Solutions found here: http://lists.openmoko.org/nabble.html#nabble-td759686 and here: http://lists.openmoko.org/nabble.html#nabble-td778718)

Finally, the best and recommended solution (as of Intrepid) would be to add that line ( vm.mmap_min_addr = 0 ) to a standalone file (named as one might wish, for instance 60-mmap-mokomakefile-fix) on /etc/sysctl.d/ .

The paths that are mentioned on this page are partially wrong

I am not sure enough what the paths should be, but - two things have changed since the section "developing with mokomakefile/How to add your own shiny new application" of this page was created: - The path where the packages are kept, and - Where to add the information that we have added a new package.

Update git to 1.5!

Version git-1.4 does not work, check your version with the command

git --version

and install at least git version 1.5 if not already present.

Fails on a 32bit machine - try again without ccache?

/bin/sh ./libtool --mode=compile     ccache     gcc -DHAVE_CONFIG_H -I.... -W... -O2 -c -o libbfd.lo build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c
ccache gcc -DHAVE_CONFIG_H -I... -W... -O2 -c  /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c -o   t shift count >= width of type
make[5]: *** [libbfd.lo] Error 1

Any insight here? --Adam 23:10, 15 May 2007 (CEST)

Try without ccache (did you get it compiled meanwhile or can we remove this?) --BernhardKaindl 23:05, 19 September 2007 (CEST)

Facing Problems with ogg libraries

just get the path and delete the .bb file that causes the problem

Building on Fedora Core 6

Install stuff needed for OpenMoko:

  1. yum install python m4 make wget curl ftp cvs monotone 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 compat-gcc-34 lynx netpbm (notice compat-gcc-34 wich was needed for FC6 (gcc 4 installed), and lynx which is needed by qemu (no fallback to wget, curl, or links at the moment and no check for it, resulting in strange "sleep" errors when trying to build without lynx).

Build it: $ make setup $ make openmoko-devel-image $ unset LD_LIBRARY_PATH $ make update-makefile && make update && make setup && make openmoko-devel-image

I have also done a $ unset LD_LIBRARY_PATH; make update-makefile && nice make update && nice make setup && nice make all (This takes several hours)

Build qemu: $ make qemu

Run it:

  1. echo 1024 > /proc/sys/dev/rtc/max-user-freq

$ make run-qemu This will bring up the OpenMoko :) Use SPACE for AUX and ENTER for POWER. Not quite the same as holding a Neo1973 in your hands I would guess, but this is the best we can do for now. Thanks!

Building on Ubuntu Feisty

MokoMakefile requires more than 512 MB of RAM + Swap space (around 1GB?).

If you need swap, please check that its size under Feisty is not null!

Bug #105490 describes the current issue and offers a workaround (23 Jul 07).

Fails trying to build bluez-utils

on Gentoo Linux, it fails compiling bluez-utils (I've tried also "make clean-package-bluez-utils" before the following command)

do a "make build-package-libusb; make clean-package-bluez-utils" and it should continue (the bluez-utils .bb is missing the libusb dependency)

openSUSE 10.1 and 10.2 workarounds

ltrace package fails to build with error:

...
checking for pid_t... yes
checking for getopt... yes
checking for getopt_long... yes
checking gelf.h usability... no
checking gelf.h presence... no
checking for gelf.h... no
configure: error: ***** gelf.h not found *****
FATAL: oe_runconf failed

FIX: edit /home/moko/build/tmp/work/armv4t-linux/ltrace-0.4-r0/ltrace-0.4/configure.ac at line 44: remove the following block:

for path in /usr/include/elfutils /usr/local/include/elfutils \
/usr/include/libelf /usr/local/include/libelf; do
if test -f ${path}/gelf.h; then
CPPFLAGS="$CPPFLAGS -I ${path}"
fi
done

( it adds /usr/include/elfutils to path, which causes cross-compile badness error )

QEMU build fails to compile USB code

/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_control':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:103: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_data':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: error: storage size of 'bt' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:132: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: warning: unused variable `bt'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_device_open':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: error: storage size of 'ctrl' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:202: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: warning: unused variable `ctrl'
make[2]: *** [usb-linux.o] Error 1

FIX: edit /home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c at line 29 add the following (before #include <linux/usbdevice_fs.h>)

#include <linux/compiler.h>

hint: there is a copy of the file in /home/moko/build/tmp/work/i686-linux/qemu-native-0.9.0+cvs20070613-r5/qemu/usb-linux.c

see: http://osdir.com/ml/emulators.kvm.devel/2007-01/msg00101.html

Cannot satisfy fstests

make openmoko-devel-image
...
| Collected errors:
| ERROR: Cannot satisfy the following dependencies for task-openmoko-debug:
|        fstests
NOTE: Task failed: /no-backup/Moko/build/tmp/work/fic-gta01-linux/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.25036
NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting

Failed on debian etch 2007-07-20 Solution from mailing list post from hardskinone, report of an irc chat

I got help in IRC channel. I do following steps
* remove fstest from oe/packages/tasks/task-openmoko.bb ,
* increase PR field by one
* make openmoko-devel-image

conflicting types for 'futimens'

if you encounter the following error:


| In file included from utimecmp.c:40: | utimens.h:2: error: conflicting types for 'futimens' | /usr/include/sys/stat.h:370: error: previous declaration of 'futimens' was here

a patch is needed because your glibc is too new. grab & enable the patch as follows

cd openembedded/packages/coreutils mv coreutils_5.3.0.bb coreutils_5.3.0.orig wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils_5.3.0.bb cd - cd openembedded/packages/coreutils/coreutils-5.3.0 wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils-5.3.0/futimens.patch cd -

Workaround for problems compiling mtd-utils

Change the line on openembedded/packages/mtd/mtd-utils_1.0.0+git.bb which reads:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=master \

to:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=a6fa706fe9e7696b4b2045edf9698c3bac07e3e3 \

which forces the recipe to use an older revision (the one which worked last time I built the image on my computer).

Be sure to remember to undo the change later, or else you will not get any new changes to that package. --CesarB 04:48, 25 July 2007 (CEST)

Note: these patches should be updated - the lzo patch is included in the current version, so backing off to the previous version and repatching seems silly. I was able to make it through this part of the build by applying the remaining patches manually. --Ted Lemon 15:44, 29 July 2007 (CDT)

Monotone segfaulting on Ubuntu Feisty Fawn/PPC

If you are running Ubuntu Feisty Fawn on a PowerPC computer you will experience problems running monotone. To fix this issue you need to install monotone as well as the libboost packages from Gutsy. The easiest way to accomplish this is to add the gutsy repositories to your sources.list and change the preferences to look like this:

Package: * Pin: release a=feisty Pin-Priority: 700

Package: * Pin: release a=gutsy Pin-Priority: -100

Package: libc6 libc6-dev tzdata util-linux libgcc1 libstdc++6 monotone Pin: release a=gutsy Pin-Priority: 800

Package: libboost-* Pin: release a=gutsy Pin-Priority: 800

After doing this install monotone in this way: apt-get -t gutsy install monotone. That should install monotone 0.35 with updated (and working) boost libraries.


Fails on ncurses install in Fedora 7 with a "tic -x" message

Adjust the following command to your system, then run it: export LD_LIBRARY_PATH=/home/moko/build/tmp/work/x86_64-linux/ncurses-native-5.4-r8/ncurses-5.4/lib Then start make again and it should pick up where it left off.

You can get a list of potential paths to use with the following command from you main moko directory: find . | grep libncurses

The basic problem is that it is linking against your main system libraries instead of the OpenEmbedded ones.

There's probably a cleaner way of handling this - please update this entry if you know it.

This has been fixed in Openembedded, see Openembedded Bug #2554 for further details.

uboot-gta01 fails to build

Changes in the GIT of U-Boot make the OpenMoko patches unapplyable. For the use of Revision cc3023b9f95d7ac959a764471a65001062aecf41 and everything will be fine for now.

Perl fails to build

After following every bit of advice I can find to 'make clean' and nuke the perl build directories, every build comes up with:

| make[1]: Entering directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7' | make[1]: *** No rule to make target `<command-line>', needed by `miniperlmain.o'. Stop. | make[1]: Leaving directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7' | FATAL: oe_runmake failed NOTE: Task failed: /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/temp/log.do_compile.19531 NOTE: package perl-native-5.8.7-r3: task do_compile: failed

Solution turned out to be editing /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7/makedepend.SH and at line 169 change the regexp to eat references to "<command.line>" to catch what was leaking through.

glibc fails to build

If you see an error like


NOTE: package glibc-2.6.1: started
NOTE: package glibc-2.6.1-r10: task do_configure: started
ERROR: function do_configure failed
ERROR: log data follows (/home/alex/moko/build/tmp/work/armv4t-angstrom-linux-gn
ueabi/glibc-2.6.1-r10/temp/log.do_configure.11446)
| NOTE: Running /home/alex/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/gli
bc-2.6.1-r10/glibc-2.6.1/configure                  --build=i686-linux
--host=arm-angstrom-linux-gnueabi                --target=arm-angstrom-linux-
gnueabi                     --prefix=/usr                   --exec_prefix=/usr
--bindir=/usr/bin                --sbindir=/usr/sbin                     --li
bexecdir=/usr/libexec               --datadir=/usr/share                    --sy
sconfdir=/etc               --sharedstatedir=/usr/com               --localstate
dir=/var                    --libdir=/usr/lib               --includedir=/usr/in
clude               --oldincludedir=/usr/include                    --infodir=/u
sr/share/info               --mandir=/usr/share/man                       --enab
le-kernel=2.4.0   --without-cvs --disable-profile --disable-debug --without-gd
--enable-clocale=gnu   --enable-add-ons=ports,nptl,libidn   --with-headers=/hom
e/alex/moko/build/tmp/staging/arm-angstrom-linux-gnueabi/usr/include   --without
-selinux     --without-fp --without-fp              ...
| configure: loading site script /home/alex/moko/openembedded/site/endian-little
| configure: loading site script /home/alex/moko/openembedded/site/common-linux
| configure: loading site script /home/alex/moko/openembedded/site/common-glibc
| configure: loading site script /home/alex/moko/openembedded/site/arm-common
| configure: loading site script /home/alex/moko/openembedded/site/arm-linux
| configure: loading site script /home/alex/moko/openembedded/site/common
| configure: loading site script /home/alex/moko/openembedded/site/common
| checking build system type... i686-pc-linux-gnu
| checking host system type... arm-angstrom-linux-gnueabi
| checking add-on ports for preconfigure fragments... am33 arm hppa m68k mips
| configure: running configure fragment for add-on nptl
| configure: running configure fragment for add-on libidn
| checking sysdep dirs... ports/sysdeps/arm/elf ports/sysdeps/unix/sysv/linux/ar
m/eabi/nptl ports/sysdeps/unix/sysv/linux/arm/eabi sysdeps/unix/sysv/linux/arm/e
abi ports/sysdeps/unix/sysv/linux/arm/nptl ports/sysdeps/unix/sysv/linux/arm sys
deps/unix/sysv/linux/arm ports/sysdeps/unix/sysv/linux nptl/sysdeps/unix/sysv/li
nux nptl/sysdeps/pthread sysdeps/pthread sysdeps/unix/sysv/linux sysdeps/gnu sys
deps/unix/common sysdeps/unix/mman sysdeps/unix/inet ports/sysdeps/unix/sysv npt
l/sysdeps/unix/sysv sysdeps/unix/sysv ports/sysdeps/unix/arm ports/sysdeps/unix
nptl/sysdeps/unix sysdeps/unix sysdeps/posix ports/sysdeps/arm/eabi ports/sysdep
s/arm/nptl ports/sysdeps/arm sysdeps/wordsize-32 sysdeps/ieee754/flt-32 sysdeps/
ieee754/dbl-64 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic
| checking for a BSD-compatible install... /home/alex/moko/build/tmp/staging/i68
6-linux/usr/bin/install -c
| checking whether ln -s works... yes
| checking for arm-angstrom-linux-gnueabi-gcc... arm-angstrom-linux-gnueabi-gcc
-march=armv4t -mtune=arm920t
| checking for suffix of object files... o
| checking whether we are using the GNU C compiler... yes
| checking whether arm-angstrom-linux-gnueabi-gcc -march=armv4t -mtune=arm920t a
ccepts -g... yes
| checking for arm-angstrom-linux-gnueabi-gcc -march=armv4t -mtune=arm920t optio
n to accept ANSI C... none needed
| checking for gcc... gcc
| checking how to run the C preprocessor... arm-angstrom-linux-gnueabi-gcc -E
| configure: error: C preprocessor "arm-angstrom-linux-gnueabi-gcc -E" fails san
ity check
| See `config.log' for more details.
| FATAL: oe_runconf failed
NOTE: Task failed: /home/alex/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-2.6.1-r10/temp/log.do_configure.11446
NOTE: package glibc-2.6.1-r10: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package glibc-2.6.1: failed
ERROR: Build of /home/alex/moko/openembedded/packages/glibc/glibc_2.6.1.bb do_co
nfigure failed
ERROR: Task 7 (/home/alex/moko/openembedded/packages/glibc/glibc_2.6.1.bb, do_co
nfigure) failed
NOTE: Tasks Summary: Attempted 448 tasks of which 440 didn't need to be rerun an
d 1 failed.
ERROR: '/home/alex/moko/openembedded/packages/glibc/glibc_2.6.1.bb' failed
NOTE: build 200808041052: completed

Try

cd source rm glibc*2.6.1* cd ../build . ../setup-env bitbake -crebuild glibc

if this doesn't help, you have to do this

cd build . ../setup-env bitbake -f -c fetch gcc-cross-initial && bitbake gcc-cross-initial && bitbake -crebuild glibc

Gettext fails to build

Gettext's build is broken unless you have emacs installed. Crazy though it seems. You will see an error like:


| WARNING: Warnings can be ignored. :-)
| if test "no" != no; then \
|         set x; \
|         list='po-mode.el po-compat.el'; for p in $list; do \
|           if test -f "$p"; then d=; else d="./"; fi; \
|           set x "$@" "$d$p"; shift; \
|         done; \
|         shift; \
|         EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| if test "no" != no; then \
|         set x; \
|         list='po-mode.el po-compat.el'; for p in $list; do \
|           if test -f "$p"; then d=; else d="./"; fi; \
|           set x "$@" "$d$p"; shift; \
|         done; \
|         shift; \
|         EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
|       else : ; fi
| mv: cannot move `elc-temp' to `elc-stamp': No such file or directory
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[5]: *** [elc-stamp] Error 1
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[4]: *** [po-mode.elc] Error 2
| make[4]: *** Waiting for unfinished jobs....
| make[4]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1'
| FATAL: oe_runmake failed

The solution is simple - install emacs (example below for debian/ubuntu) and try again:


sudo apt-get install emacs
make clean-package-gettext-native-0.14.1-r5
make openmoko-devel-image

Building OpenMoko with chroot

There may be hundreds of issues which may cause that OpenMoko fails to build on your system, so it might be more straightforward to just install a standardized build environment in which the openmoko build runs in chroot, independent of your distribution.

There is now a (not fully working) script which is able to set up a 32-bit openSUSE 10.3 build environment for building OpenMoko posted on distro-devel: [1]

On gentoo and debian-like distribution, you can use debootstrap to quickly setup a base chroot.

Please note that in addition to the common /dev, /sys and /proc, /dev/shm should also be mounted with --bind option. It is at least required to build a qtopia-x11 image. (Otherwise you will get some semaphore 'function not implemented' errors at qtopia-x11 installation stage).

Fails compiling binutils-cross on Gentoo/AMD64 and openSUSE/x86_64

make setup works fine, but when running make openmoko-devel-image it fails with the following:

| make[4]: Entering directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[4]: Nothing to be done for `install'.
| make[4]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[3]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty'
| make[2]: Nothing to be done for `install-target'.
| make[2]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| make[1]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib/gcc-lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross: No such file or directory
| mv: cannot stat `build/tmp/cross/lib/libiberty.a': No such file or directory
NOTE: Task failed: build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/temp/log.do_stage.9730
NOTE: package binutils-cross-2.18-r0: task do_populate_staging: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of openembedded/packages/binutils/binutils-cross_2.18.bb do_populate_staging failed
ERROR: Task 1641 (openembedded/packages/binutils/binutils-cross_2.18.bb, do_populate_staging) failed
NOTE: Tasks Summary: Attempted 107 tasks of which 107 didn't need to be rerun and 1 failed.
ERROR: 'openembedded/packages/binutils/binutils-cross_2.18.bb' failed
make: *** [openmoko-devel-image] Error 1

The final reason why the build cannot continue is: mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

The lib64 issue

Likely, Gentoo/AMD64 uses lib64 instead of lib as the library directory for x86_64 libraries. It's l likey that many (or all?) AMD64 distributions do for their 64-bit binaries. On openSUSE-x86_64, the same happens. Debian/x86-64 seems to either not use lib64 or is somehow supported by the openmoko distribution.

On multilib/lib64 platforms like Gentoo/x86_64 and openSUSE-x86_64, the openmoko build runs into a final problem at the end of build: It tries to use fakeroot which uses LD_PRELOAD to fake a different root directory and in the final stages, after hours of compiling, fakeroot execution causes warning messages because on multilib/lib64 systems as they have two versions of many libraries, the 64-bit libraries are in /lib64, /usr/lib64 and oder lib64 paths, while the 32-bit libraries are in /lib, /usr/lib and other lib paths. Some tool on these lib64 distributions are adapted to install 64-bit libraries to lib64, but this seems to fail when cross-compiling.

At least on openSUSE-10.3 the missing libiberty.a was installed to build/tmp/cross/lib64/libiberty.a, which looks wrong, and it is if this libiberty.a file contains 32-bit arm objects. If it contains 64-bit x86_64 objects, it's fine, but openembedded/openmoko is not expecting it in a lib64 directory. I am not sure what is the case.

The lib64 fakeroot issue requires to change the openembedded build scripts, which is doable. But it's not very easy to find the correct script and patch it correctly. If you feel adventourus, go ahead and try to build openmoko on a lib64 distribution, but it's easyer to set up a complete 32-bit chroot environment and run a normal build in it.

After seeing this, I assumed that openmoko/openembedded was clearly not tested with lib64 build hosts and since that would mean that even if I'd fix that error, many others could follow, and as I was not interested to fix the lib64 bugs but rather wanted to see something running first, I decided to make openmoko/openembedded think that it was running on a normal 32-bit non-lib64 machine.

There are several ways to do that:

  • You install an 32bit x86-Linux somewhere and use that for building:
    • Do a native install and dual-boot the 32bit x86-linux (That's for dummies which do not know the other tricks)
    • Install 32bit x86-Linux in a virtual machine (Takes powerful hardware and has some overhead too). Use VirtualBox, for example.
  • you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience). See the gentoo guide

Building on SuSE Linux 10.3-AMD64 with -m32 (not finished)

Install the following packages for the 32-bit C/C++ compiler target option -m32 to work and to compile what is needed

gcc42-32bit gcc42libgcc42-32bit glibc-devel-32bit libstdc++-devel-32bit ncurses-devel-32bit zlib-devel-32bit (maybe also gtk2-devel-32bit)

The openSUSE 10.3-AMD64 has no libopenssl-devel-32bit, but you can install the 32-bit rpm from the i586 10.3 rpm tree:

libopenssl-devel

You should also make sure that gdbm-devel is not installed. The multilib support in ld has an issue which surfaces when it is called from perl's Configure script to complile a test program with -Lgdbm. If gdbm-devel is installed, it finds /usr/lib64/libgdbm.so, but since it's not compatible with 32-bit, it skips it, but also does not search the specified -Lpath where the OpenEmbedded-built libgdbm.so is already installed. To work around this, uninstall /usr/lib64/libgdbm.so with: rpm -e gdbm-devel

Note these need to be the 32-bit cpp33 and gcc33 rpms as the 64-bit gcc33 rpms for openSUSE do not support the 32-bit target.

To make the OpenMoko build think that its running on 32-bit i686, use linux32 (changes uname -m to i686 in the new shell):

linux32 bash

And set up gcc scripts which force the use of gcc-3.3 (it can only generate 32-bit assembly) for all compilation:

mkdir bin;cd bin echo '/usr/bin/${0##*/}-3.3 -m32 "$@"' >gcc echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld echo '/usr/bin/${0##*/} --32 "$@"' >gas sed -i '1i#!/bin/sh' gcc gas ld chmod 755 gcc gas ld ln -s gcc cc ln -s gcc c++ ln -s gcc g++ ln -s gas as echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32 cd -

Then set the path and test it:

source bin/.setup-gcc-m32 type gcc

More package requirements

On my system (Kubuntu 6.10) build failed with message "ERROR: QEMU requires SDL or Cocoa for graphical output" because package libsdl-image1.2-dev was missing. Use apt-get install libsdl-image1.2-dev to install. Additionally I had to install packages cvs and diffstat. I was also asked to install Psyco JIT Compiler (package python-psyco) to increase performance. Nevertheless make flash-qemu-local took some hours, but now I finally can get an impression of the phone that I am looking for! -- Nichtich 00:26, 20 September 2007 (CEST)

pango-directfb failed to build due to missing Glib 2.14.x

The latest(as of Sept. 25, 2007) build started to fail with the following error:

| checking for GLIB... no | configure: error: | *** Glib 2.14.0 or better is required. The latest version of | *** Glib is always available from ftp://ftp.gtk.org/. | FATAL: oe_runconf failed NOTE: Task failed: /media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\ pango-directfb-1.18.1-r0/temp/log.do_configure.19927 NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed ERROR: TaskFailed event exception, aborting NOTE: package pango-directfb-1.18.1: failed ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\ pango-directfb_1.18.1.bb do_configure failed

The Glib included in the build tree seems to be only 2.12.12, so looks like something is broken in term of dependency.

This had happened on both of Fedora 7 and Debian Etch. I am running the latest MokoMakefile with OM-2007.2. The funny thing is that the build had worked only couple nights ago. Any idea? I will update anything I find here and also on my blog(see my user profile). ttz Wed Sep 26 12:17:33 CDT 2007

pango-directfb had been removed from OE for now due to the report of it breaking builds like OpenMoko.

ttz Thu Oct 4 10:20:12 CDT 2007

uicmoc4 failes to compile

This is solved by installing libz-dev

Or, look at Bug #747

svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'

osiris$ make update ... Fetching external item into 'trunk/src/target/OM-2007.2/applications/openmoko-today2/libkoto' svn: REPORT request failed on '/repos/tasks/!svn/vcc/default' svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com) make: *** [update-openmoko] Error 1

osiris$ cd openmoko/trunk/src/target/OM-2007.2/applications/openmoko-today2//libkoto/ osiris$ svn up -r HEAD svn: REPORT request failed on '/repos/tasks/!svn/vcc/default' svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)

Anyone know about this one? --Blackh 00:11, 12 October 2007 (CEST)

bootparam_prot.h fails to install in glibc-intermediate-2.5 package (Debian sid)

| install: cannot stat `/home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc/bootparam_prot.h' No such file or directory NOTE: Task failed: /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ glibc-intermediate-2.5-r7/temp/log.do_stage.3940

For some reason, on Debian, the rpcgen command needs "-Y /usr/bin" added to the end of it or it won't work ("cannot find any C preprocessor (cpp)"). This can be fixed by hand...

cd /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc for f in *.x ; do rpcgen -h $f -o ${f%%.x}.h -Y /usr/bin ; done

This command will generate the right files and you can resume the build with

make openmoko-devel-image

Here is a better fix - put this script, calling it rpcgen, somewhere in your PATH before /usr/bin:

  1. !/bin/sh

exec /usr/bin/rpcgen -Y /usr/bin "$@"

--Blackh 05:17, 12 October 2007 (CEST)

Cannot find SVN openmoko-terminal2

I'm having an issue when building MokoMakeFile where it is unable to find http://svn.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-terminal2. Any ideas on how to fix this?

--cartera

problem with make openmoko-devel-image

when i try to do my first make openmoko-devel-image I obtain this error:

NOTE: Running task 844 of 5445 (ID: 671, /home/xraver/moko/openembedded/packages/linux/linux-openmoko_2.6.24+git.bb, do_fetch)
NOTE: package linux-openmoko-2.6.24+git20080422: started
NOTE: package linux-openmoko-1_2.6.24+git20080422-r0: task do_fetch: started
NOTE: fetch http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
--08:47:41--  http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
=> `/home/xraver/moko/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz'
Risoluzione di downloads.openmoko.org in corso... 88.198.93.219
Connessione a downloads.openmoko.org|88.198.93.219:80... connesso.
HTTP richiesta inviata, aspetto la risposta... 404 Not Found
08:47:41 ERRORE 404: Not Found.

In this location http://downloads.openmoko.org/sources/ the file git_git.openmoko.org.git.kernel.git_4194.tar.gz does not exist. Any solutions?

--Giorgio Ravera

they have problems with server, try later. that helped me ...

--bubbas


I have the same error as bubbas... any ideas?

--jas

Wishlist: Make qemu optional

Hi,

I’ve just set up MokoMakefile, and after make setup I tried to get a package with make build-package-openmoko-messages2, but it’s spending a lot of time and disk space on building native libraries and qemu – something that I have not asked for. It would be nice if I could build packages for my phone without having to build unneccessary stuff.

Thanks, Joachim

SVN Certificate issues for Gentoo users

Note for Gentoo users: I think Portage creates a ~/.subversion directory as root if you've ever compiled a svn ebuild via "sudo emerge". If this happens, certificates won't be saved, so you have to take back ownership of the directory:

chown -R $USER ~/.subversion

Before running a svn co from the openmoko svn server to accept the certificate, otherwise the authentication information will not be saved. kelvie 06:05, 18 July 2008 (UTC)

glibc, task do_package_write_ipk: "Package name contains illegal characters"

Package glibc-2.6.1-r11: task do_package_write_ipk may return an error while dealing with locale-base-* packages: Error: Package name contains illegal characters, (other than [a-z0-9.+-]) for no obvious reason. I've found that setting LANG=C (instead of nb_NO.utf8) seems to fix this problem: LANG=C make openmoko-devel-image or export LANG=C make openmoko-devel-image --StianEllingsen 21:44, 28 August 2008 (UTC)