Building dependant packages

From Gnash Project Wiki

Jump to: navigation, search

These examples are setup to show how to cross build the other software packages Gnash depends on. All of these examples are done for those of us that are using the traditional style GCC cross tools. Some build environments, like Scratchbox, etc... have alternate ways of doing this that can be much easier, if your target uses those environments.


Dependant Libraries

The libraries needed by either Gnash, or whether sucked in by other dependent packages, here's the list:

There are also two systems libraries Gnash depends on. Pthreads, which should be included in every OS these days, and optionally OpenGL libraries, if you have a hardware accelerated graphics card, and don't mind proprietary binary blobs.

If you use the GTK GUI for Gnash, you'll also need to install

Cross compiling Boost

The best way to cross compile the Boost libraries is by hacking the post configure config file. First, run configure, setting your --prefix directory and other options as usual. This creates a file called user-config.jam which looks something like this:

# Boost.Build Configuration
# Automatically generated by Boost configure
# Compiler configuration
using gcc ;

To tell the Boost build scripts where to look for your GCC cross compiler tools, change the line using gcc ; to something like example. The spaces are important.

using gcc : : /usr/local/android-arm/bin/arm-linux-eabi-gcc ;

Newer versions of boost have rename the config file to project-config.jam, but the editing change is the same. I also edited the paths set below, although you can also set them on the command line to bjam.

# These settings are equivalent to corresponding command-line
# options.
option.set prefix : /usr/local/android-arm/sysroot/usr ;
option.set exec-prefix : /usr/local/android-arm ;
option.set libdir : /usr/local/android-arm/usr/lib ;
option.set includedir : /usr/local/android-arm/usr/include ;

Boost is a bit schizophrenic when it comes to configuring and building. You get your choice (sort of) between cmake, bjam, or autoconf. I usually wind up using bjam, as that's the primary way boost developers do builds. I've tried the cmake and autoconf versions too, but only for native builds. To build, invoke ./bjam -d+2 --with-thread --with-date_time install for the minimal build with enough debug info to see if things go wrong.

Cross compiling FFmpeg

FFmpeg doesn't use autotools, so it configures differently. To build for an arm-linux based device, this should work:

./configure --cc=arm-linux-gcc --cross-compile

Just as a note, I have problems compiling ffmpeg with some versions of gcc, namely 4.1.x

Newer version of ffmpeg use --enable-cross-compile instead.

Cross compiling SDL

SDL is setup to correctly cross configure, and build with cross tools out of the box. I use this for my builds that use X11:

./configure --host=arm-linux --prefix=/opt/crosstools/arm-linux --enable-video-directfb=no

For platforms without X11, and just a raw framebuffer, configure SDL this way instead:

./configure --prefix=/opt/crosstools/arm-linux --host=arm-linux --enable-video-fbcon --disable-video-x11 --disable-dga --disable-esd

Cross compiling AGG (Antigrain)

./configure --host=arm-linux --prefix=crosstools/arm-linux

To get AGG to cross compile with Mingw32, I configure like this when using the packaged Mingw32 tools on Fedora.

./configure --host=i686-pc-mingw32 --build=$CANON --prefix=/usr/i686-pc-mingw32/sys-root/mingw FREETYPE_CFLAGS=-I/usr/i686-pc-mingw32/sys-root/mingw/include/freetype2 FREETYPE_LIBS="-L/usr/i686-pc-mingw32/sys-root/mingw/lib -lfreetype2"

Cross compiling libCurl

Curl is setup to correctly cross configure, and build with cross tools out of the box. The one main change is you have to specify --without-ssl, as SSL requires urandom devices support, which you can't configure cross usually. I use this for my builds:

./configure --host=arm-linux --prefix=/opt/sdg/arm/oe-fam084/arm-linux --without-ssl

Cross compiling on Debian / Ubuntu

Debian compiles sudo to set the path to the sudo'ed user's path. If you find that "sudo make install" fails to find arm-linux-ranlib (e.g.), then do the following to preserve your path.

sudo env PATH=$PATH make install

If You Have Problems

if you are having problems building a particular package, there are various ways to hack the build into existance. The primary way is to just define the tool names in your shell environment:

export TARGET=arm-linux
export CC=${TARGET}-gcc
export GCC=${TARGET}-g++
export AR=${TARGET}-ar
export RANLIB=${TARGET}-ranlib
export LD=${TARGET}-ld

And then any autoconf script, whether it has explicit cross configuration support or not will use these overrides for the default too names. If for some perverted reason this still doesn't work, the final fallback is to invoke make with the names of the same tools:


If that doesn't work, it's time to track down a cross tools guru, or go slam down a few beers and try again.

Cross compiling Environments

  • Scratchbox - Scratchbox is a "fake native environment", that makes it easy to build software packages that don't have support for being cross configured or cross compiled. Scratchbox supports both native targets, and multiple cross targets.
  • Maemo - Maemo is used for the Nokia series of internet tablets (770/800/810), and is based on an older version of scratchbox.
  • Mamona - This is a derived version of Maemo, but uses only free or open source tools.
  • Cross tools - The old style, tried and true way for us cross compiling dinosaurs. Here you build up your own tool chains, development packages, the whole works.
  • OpenEmbedded - This was the original project to tailor Debian for smaller devices. it uses bitbake for a build system, and monotone for source control, so as a result, packages rarely build. This is an unstable source tree, to get any work done most people use one of the following Open Embedded derived environments.
  • Poky - Poky is a trimmed down and stable version of Open Embedded.
  • OpenMoko - OpenMoko is a smart phone distribution, based on Open Embedded.
  • Qtopia - Qtopia is a commercial software stack for PDAs and phones, is is currently used on Motorola phones.

Native Building

The folks have used a combination of cross-compiling (many people use their toolchain, e.g. SDG) and native compilation. Using the iPAQ's dual-PCMCIA sleeve, they configured a build cluster using a PCMCIA Ethernet card and PCMCIA hard drive. The build cluster used Debian-ARM. The Ethernet mounted a central disk store.