Seems to have worked for me --[[User:Urzumph|Urzumph]] 23:46, 20 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. --[[User:Cgerum|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:

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/ .

+

+

=== different solution ===

+

Disable the sanity Checker just by <pre>touch conf/sanity.conf</pre> in your build dir.

+

== The paths that are mentioned on this page are partially wrong ==

== 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:

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:

(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'').

(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:

Build it:

−

$ make setup

+

$ make setup

−

$ make openmoko-devel-image

+

$ make openmoko-devel-image

−

$ unset LD_LIBRARY_PATH

+

$ unset LD_LIBRARY_PATH

−

$ make update-makefile && make update && make setup && make openmoko-devel-image

+

$ make update-makefile && make update && make setup && make openmoko-devel-image

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

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).

mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

+

mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

=== The lib64 issue ===

=== The lib64 issue ===

−

Likely, Gentoo/AMD64 uses lib64 instead of lib as the library directory for x86_64 libraries. It's l likey that may (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.

+

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.

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.

Line 331:

Line 533:

There are several ways to do that:

There are several ways to do that:

−

* You install an IA32-Linux somewhere and use that for building:

+

* You install an 32bit x86-Linux somewhere and use that for building:

−

** Do a native install and dual-boot the IA32-linux (That's for dummies which do not know the other tricks)

+

** Do a native install and dual-boot the 32bit x86-linux (That's for dummies which do not know the other tricks)

−

** Install IA32-Linux in a virtual machine (Quite some setup and has some overhead too)

+

** Install 32bit x86-Linux in a virtual machine (Takes powerful hardware and has some overhead too). Use [http://gentoo-wiki.com/VirtualBox 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)

+

* you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience). See [http://www.gentoo.org/proj/en/base/amd64/howtos/chroot.xml the gentoo guide]

−

* Or you can install a 32-bit development system on the 64-bit host (suppored on openSUSE, should be possible with Gentoo/AMD64 too)

+

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

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

Line 341:

Line 542:

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

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

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:

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

+

libopenssl-devel

You should also make sure that gdbm-devel is not installed.

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:

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

+

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.

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.

Line 355:

Line 556:

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

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

+

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:

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

+

mkdir bin;cd bin

−

echo '/usr/bin/${0##*/}-3.3 -m32 "$@"' >gcc

+

echo '/usr/bin/${0##*/}-3.3 -m32 "$@"' >gcc

−

echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld

+

echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld

−

echo '/usr/bin/${0##*/} --32 "$@"' >gas

+

echo '/usr/bin/${0##*/} --32 "$@"' >gas

−

sed -i '1i#!/bin/sh' gcc gas ld

+

sed -i '1i#!/bin/sh' gcc gas ld

−

chmod 755 gcc gas ld

+

chmod 755 gcc gas ld

−

ln -s gcc cc

+

ln -s gcc cc

−

ln -s gcc c++

+

ln -s gcc c++

−

ln -s gcc g++

+

ln -s gcc g++

−

ln -s gas as

+

ln -s gas as

−

echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32

+

echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32

−

cd -

+

cd -

Then set the path and test it:

Then set the path and test it:

−

source bin/.setup-gcc-m32

+

source bin/.setup-gcc-m32

−

type gcc

+

type gcc

== More package requirements ==

== More package requirements ==

Line 385:

Line 586:

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

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

−

| checking for GLIB... no

+

| checking for GLIB... no

−

| configure: error:

+

| configure: error:

−

| *** Glib 2.14.0 or better is required. The latest version of

+

| *** Glib 2.14.0 or better is required. The latest version of

−

| *** Glib is always available from ftp://ftp.gtk.org/.

+

| *** Glib is always available from ftp://ftp.gtk.org/.

−

| FATAL: oe_runconf failed

+

| FATAL: oe_runconf failed

−

NOTE: Task failed:

+

NOTE: Task failed:

−

/media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\

+

/media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\

−

pango-directfb-1.18.1-r0/temp/log.do_configure.19927

+

pango-directfb-1.18.1-r0/temp/log.do_configure.19927

−

NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed

+

NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed

−

ERROR: TaskFailed event exception, aborting

+

ERROR: TaskFailed event exception, aborting

−

NOTE: package pango-directfb-1.18.1: failed

+

NOTE: package pango-directfb-1.18.1: failed

−

ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\

+

ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\

−

pango-directfb_1.18.1.bb do_configure failed

+

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

The Glib included in the build tree seems to be only 2.12.12, so looks like something

is broken in term of dependency.

is broken in term of dependency.

−

This had happened on both of Fedora 7 and Debian Etch. I am running the latest

+

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

+

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).

couple nights ago. Any idea? I will update anything I find here and also on my blog(see my user profile).

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?

+

+

--[[User:xraver|Giorgio Ravera]]

+

+

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

+

+

--[[User:Bubbas|bubbas]]

+

+

+

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

+

+

--[[User:jas|jas]]

+

+

== Wishlist: Make qemu optional ==

+

+

Hi,

+

+

I’ve just set up MokoMakefile, and after <tt>make setup</tt> I tried to get a package with <tt>make build-package-openmoko-messages2</tt>, 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:

+

+

<pre>

+

chown -R $USER ~/.subversion

+

</pre>

+

+

Before running a svn co from the openmoko svn server to accept the certificate, otherwise the authentication information will not be saved.

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:

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/ .

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.

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:

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!

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)

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:

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.

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.

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).

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

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:

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)

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.

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.

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)

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)

(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).

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:

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.

Gettext fails to build

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

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.

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:

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 may (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 IA32-Linux somewhere and use that for building:

Do a native install and dual-boot the IA32-linux (That's for dummies which do not know the other tricks)

Install IA32-Linux in a virtual machine (Quite some setup and has some overhead too)

you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience)

Or you can install a 32-bit development system on the 64-bit host (suppored on openSUSE, should be possible with Gentoo/AMD64 too)

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

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:

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:

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.