Building for ltib

From Gnash Project Wiki

Jump to: navigation, search

Contents

Building Gnash For Ltib

Ltib is a cross build system used by Freescale for their i.MX* series of ARM based systems. To build Gnash under ltib, requires dependencies that aren't part of the release yet. To use these, install the spec files in a subdirectory in dist/lfs-5.1/, and the install the tarballs in /opt/freescale/pkgs/.

By default, you'll need to use ./ltib -m config to build curl, libjpeg, bzip2, freetype, and fontconfig, which are required later on. The other packages we get to add. Rather than require the config files to be patched, here's the two files in their entirety. These replace the existing ones in config/userspace. packages.lkc pkg_map. (--Rob 22:28, 1 December 2010 (MST) updated) The additional packages Gnash needs have all been added to a Gnash subcategory, and can be built separately, or if you select just gnash, it'll automatically select all the dependencies.

I originally used the latest L2.6.31_10.08.01_SDK snapshot from Freescale, which has some improvements and a few subtle differences from the older snapshot. The main difference is the spec files have a %define %pkg as the top line, which has to be adjusted for the proper location of the rootfs. I migrated all my patches to the older L2.6.31_09.12.01_SDK, which is what these patches are currently setup to work under. Tweaking the %pkg path should be all that's necessary for any of these spec files to work under wither snapshot or both. I'm currently using these patches under the L2.6.31_10.07.11_ER snapshot.

For those that don't feel like building all the dependencies, you can grab a binary tarball of my rootfs/usr/{include,lib}. Just install this tarball where your rootfs is. Note that this is for the older snapshot. (--Rob 18:46, 3 February 2011 (MST) This rootfs was updated)

--Rob 18:06, 21 December 2010 (MST) I've been having problems getting EGL to initialize, and then I noticed Freescale had a new Ltib snapshot, so I grabbed L2.6.35_10.11.01_ER to see if it would help with my problems. Once nice thing, it uses GCC 4.4.5, which has many more optimizations than the older GCC 4.2.1.A bunch more things worked that didn't before. So I got to upgrade boost, so many nasty compiler warnings went away.

Here's a Screenshot of Gnash running under ltib on a Freescale Babbage board. This is also using OpenVG acceleration.

Touchscreen Calibration

Currently Gnash uses tslib to talk to the touchscreen or tablet. TSlib has a calibration program called ts_calibrate that needs to be run before the coordinates match the display. It uses 5 points to calculate the calibration parameters, and then stores the result in /etc/pointercal. Once this file is created, tslib is calibrated. You can then ts_test to see if your coordinate system now matches the display. I had to set these variables in my environment to get the tslib utilities to run.

export TSLIB_CONFFILE=/usr/etc/ts.conf
export TSLIB_TSDEVICE=/dev/input/ts0
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0

DejaGnu

Although this isn't used by the code, many of the test cases do use DejaGnu. The unit testing API for DejaGnu doesn't need the rest of the framework, so this header file needs to go in rootfs/usr/include if you want to build test cases. You can grab that from here: [dejagnu.h]

mtd-utils

mtd-utils is almost the same but -Werror was removed from a Makefile so it would compile on an x86_64. On an x86 build machine, this hack is not necessary. It's a minor issue of between the sizes of data types used in a comparison statement.

[mtd-utils-201006.tar.bz2][mtd-utils-201006.tar.bz2.md5]

This patch was unnecessary with the L2.6.31_10.07.11_ER snapshot.

SDL

SDL was missing. You don't need this if you configure Gnash without sound support.

[sdl.spec] [SDL-1.2.14.tar.gz] [SDL-1.2.14.tar.gz/md5]

Giflib

Giflib was n ltib cvs.

[giflib.spec] [giflib-4.1.6.tar.bz2] [giflib-4.1.6.tar.bz2.md5]

AGG

AGG was missing.

[agg.spec] [agg-2.5.tar.gz] [agg-2.5.tar.gz.md5]

If you have a problem with ltib spawning processes out of control till your machine locks up when compiling AGG. here's a version cross compiled with the exact same compiler, but without ltib going crazy. You can grab my executables of this from here: [ltib-agg.tar.bz2] [ltib-agg.tar.bz2.md5]

Boost

Boost was there, but not built by default. This patched version only builds the 3 packages Gnash uses. With the older ltib snapshots I was using these files:

[boost139.spec] [boost_1_39_0.tar.bz] [boost_1_39_0.tar.bz.md5]

When I upgraded to L2.6.35_10.11.01_ER, I also upgraded boost, since the newer G++ could handle it finally.

[boost.spec] [boost_1_39_0.tar.bz] [boost_1_39_0.tar.bz.md5]


libpng

Ltib cvs has libpng 1.2, but Gnash wants libpng 1.4. We can't just replace the older libpng, as other packages have a dependency on that version. so applying this spec file is different than the others. Create a new directory libpng14. Put this spec file in that directory. If you applied the patch for the config menu, then you'll see two libpngs listed, one under the Gnash category, and the other where it usually is with the other packages. The config menu patch also fixes the dependencies for all the existing applications to use the old libpng12.

--Rob 10:14, 2 December 2010 (MST) You don't need libpng14 anymore either, as the current Gnash source have an ifdef to handle the much older version of libpng.

[libpng14.spec [libpng-1.4.4.tar.bz2] [libpng-1.4.4.tar.bz2]

Files

A direct link to the files if you just want to grab all of them is here: [Ltib Files]

Gnash

Gnash was missing. (--Rob 10:09, 1 December 2010 (MST) updated)

[gnash.spec ] --Rob 14:00, 31 Oct 2011 (MST) updated

[gnash-20111030.tar.bz2] [gnash-20111030.tar.bz2.md5]

Ffmpeg

The version of ffmpeg shipped with ltib is over 2 years old, so I build a newer one for Gnash in case anyone wants to add multimedia support. This build has some ARM optimizations disabled till I sort out issues with the unfortunately old version of GCC. If you just want the headers and libraries, then grab this binary tarball of the latest ffmpeg headers and libraries for ltib. One of these days I'll upgrade the compiler to a newer Code Sourcery one, and enable all the ARM optimizations.

[ffmpeg.spec ] (--Rob 16:28, 1 December 2010 (MST) updated)
[ffmpeg-export-20101201.tar.bz2] [ffmpeg-export-20101201.tar.bz2.md5]

Cross Compiling on Ubuntu

ltib comes with two compilers, gcc 4.1.2 and gcc 4.3.3. Since many improvements to the ARM cross compilers have been done since then, I also have cross compiled in the traditional sense for ltib using the Linaro versions of GCC 4.5 available via apt-get for Ubuntu users. The only downside with using a cross compiler this way is you need to do some serious path munging, as normally all the magic paths are built into the cross compiler. So we can't even configure the normal way. For these examples, the top of where I have ltib installed is /opt/L2.6.31_10.07.11_ER, and my rootfs is under /opt/L2.6.31_10.07.11_ER/ltib/rootfs.

To start, we redefine a few variables all the configure script will use. You can pass these to each configure script, or you can set them as environment variables, where each configure will pick them up. Our main problem is the Ubuntu cross compilers have no concept of BSP (Board Support Package), so you can't link an executable without some munging of the link options. For compiling, we want to use all the headers and libraries in our existing ltib installation. So to put a new path in front of all the others, we use GCC's --sysroot= option to point to our existing ltib rootfs. This option has to be applied to all invocations of GCC. The --sysroot= could also be in CPPFLAGS instead of overloading CC, but I've found sometimes that causes problems with some packages, so I just overload CC and CXX as the safest behaviour. You also have to overload the binutils. Here's the set of them:

export CC=arm-linux-gnueabi-gcc --sysroot=/opt/L2.6.31_10.07.11_ER/ltib/rootfs/usr export CXX=arm-linux-gnueabi-g++ --sysroot=/opt/L2.6.31_10.07.11_ER/ltib/rootfs/usr export STRIP=arm-linux-gnueabi-strip export AR=arm-linux-gnueabi-ar export RANLIB=arm-linux-gnueabi-ranlib

Then just configure a package like you normally would when cross compiling, setting the build-host and target-host options like this --build=x86_64-unknown-linux-gnu --host=arm-linux-gnueabi. You'll also need a prefix. To install cross compiled packages with the normal ltib rootfs, add this when configuring --prefix=/opt/L2.6.31_10.07.11_ER/ltib/rootfs/usr.

The first few times you do this, it's a good idea to do a "grep _CFLAGS Makefile" to make sure all the files were found in the right sysroot path. Then it's time to compile. Some applications correctly use the configured cross compiler, but some don't. If you have problems after configuring with getting things to compile, then you can force make to use the correct values by overriding them on the command line.

make CXX="arm-linux-gnueabi-g++ --sysroot=/opt/L2.6.31_10.07.11_ER/ltib/rootfs/usr
      -I/opt/build-ltib/rootfs/usr/include" LDFLAGS=-Lopt/build-ltib/rootfs/usr/lib

I know, it's ugly, but it does do the trick when you are building dependencies for a project, and just want all them to be done, so you can work on the actual project you intend to. These examples assume you want to build a a small standalone sysroot, a good idea when playing with multiple ARM compiler versions.

../pkgs/agg-2.5/configure --build=x86_64-unknown-linux-gnu --host=arm-linux-gnueabi --prefix=/opt/build-ltib/rootfs/usr

../pkgs/curl-7.16.2/configure --build=x86_64-unknown-linux-gnu --host=arm-linux-gnueabi --prefix=/opt/build-ltib/rootfs/usr

../pkgs/ffmpeg-export-2010-12-01/configure --prefix=/opt/build-ltib/rootfs/usr --cc=/usr/bin/arm-linux-gnueabi-gcc --enable-cross-compile --target-os=linux --arch=arm5te --disable-ffplay --disable-ffprobe --disable-ffserver

/opt/build-ltib/pkgs/freetype-2.3.9/builds/unix/configure --prefix=/opt/build-ltib/rootfs/usr --build= --host=arm-linux-gnueabi

../pkgs/giflib-4.1.6/configure --build=x86_64-unknown-linux-gnu --host=arm-linux-gnueabi --prefix=/opt/build-ltib/rootfs/usr

./pkgs/gnash-0.8.9dev/configure --build=x86_64-unknown-linux-gnu --host=arm-linux-gnueabi --prefix=/opt/build-ltib/rootfs/usr --with-sysroot=/opt/build-ltib/rootfs/usr --enable-gui=fb --enable-media=ffmpeg --enable-renderer=agg --disable-testsuite --enable-sound=none --disable-jemalloc --disable-rpath --enable-hwaccel=none

Using Gnash From Git

If you want to use Gnash from our git source repository, but work with ltib, here's the simple steps to change the build. First, grab Gnash via Git:

git clone git://git.sv.gnu.org/gnash.git

then cd into the top level source directory, and run ./autogen.sh. Then ./configure. This will configure the build, and produce a Makefile. Once you have the Makefile, you can do the rest of these stages.

First make the source tar file. We use bzip, but gzip works just as well. Whatever the value of VERSION is, becomes the specific name of the tar file. By default without VERSION set, the value is 0.8.9dev. That works too, but I prefer to datestamp my tar files.

export VERSION=20110101
make dist-bzip2 VERSION=${VERSION} && md5sum gnash-${VERSION}.tar.bz2 gnash-${VERSION}.tar.bz2.md5

Then just copy the result to /opt/freescale/packages/ on the build machine.

scp gnash-${VERSION}.tar.bz2* build:/opt/freescale/pkg/

After copying you can just run ltib, if you have Gnash enabled with the menu patches above. This will copy the tar file to rpm/SOURCES, untar it in rpm/BUILD/gnash-${VERSION}, build, install, and deploy it. I often am doing partial builds to save time, so instead after copying the files I do this, which only untars the tarball.

./ltib -m prep -p gnash

If you have an old build leftover, and this step errors out, just remove the rpm/SOURCES/gnash-${VERSION} and rpm/BUILD/gnash-${VERSION} files and then it'll work.

Then changes the version in the Gnash spec file used to build the rpm to the version you are using now. In the very top of the spec is this line, just change the date. The file is dist/lfs-5.1/gnash/gnash.spec.

Version:        20110101

If you change a file and just want a quick rebuild, you can rsync or scp the files to the build directory on the build machine. Then only the changed files are recompiled. This saves much time when making lots of little changes during debugging. Btw, enabling the native GDB in your ltib builds is a good idea.

rsync -avc librender gui build:/opt/L2.6.35_10.11.01_ER/ltib/rpm/BUILD/gnash-${VERSION}/

After copying the files over you don't want to run with ltib's default, as that will rebuild everything from scratch using the original tar file. Instead we just build and deploy to the rootfs like this:

./ltib -m scbuild -p gnash && ./ltib -m scdeploy -p gnash

If you are using an NFS mounted root file system, you can just execute gnash without rebooting.

How To Use GDB

I build the native GDB as part of ltib, but there are a few tricks you can use to make it easier. The first thing to do is mount your sources to a subdirectory from your work machine. Either that or copy them someplace in the rootfs. Once you have access to the source, we have to tell GDB how to find them. We do this by creating a ${HOME}/.gdbinit file. Here's the contents I use.

set history save on
dir /mnt/nfs/gnash-${VERSION}/libdevice:/mnt/nfs/gnash-${VERSION}/librender:/mnt/nfs/gnash-${VERSION}/gui
set args -vv --renderer=openvg /home/user/test.swf
tb main
run

What this does is save all the commands you type, so future debugging sessions can just scroll back through them to repeat the command. This can save much typing. The next command specifies where we mounted the sources from. GDB will use these paths to lookup source files. Then the default command line arguments to Gnash can be specified. Finally I do a simple temporary breakpoint on main, and then run. This is because the startup time with the native GDB is slow. Once at the breakpoint, the symbol table is loaded, and it's easier to list files or set breakpoints.

If you have problems, make sure your binary isn't stripped. The current gnash.spec files has the stripping step commented out, but usually you do build stripped executables. You can tell if you executable is stripped using with file or nm.