This manual is a work in progress. The kind reader is encouraged to report inconsistencies and errors to the author.
Copyright © 2008 Damien Lespiau
About this manual
The latest version of this document can be found on the Poulpy's web site.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License (GFDL), Version 1.1 published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You can find a copy of the GFDL on the FSF web site.
| Revision History | |
|---|---|
| Revision 0.1 | 2008-07-31 |
| Initial revision | |
Table of Contents
Abstract
Poulpy is a tool to cross-compile libraries for Windows® from a linux box. It comes with recipies to build some Open Source libraries and is focused on building glib-based ones. It's then possible to use these libraries to cross-compile your application using the building environment you are familiar with and get a Windows® version of your application. The users targeted by Poulpy are UNIX developpers that do want to use the OS and the tools they are used to in order to build Windows® binaries.
Poulpy is not a from scratch effort but a fork of OpenEmbedded/Poky, tuned to build Windows® binaries; It uses BitBake as its tasks manager.
Here are a few things to check before starting to use Poulpy:
Install a mingw32 cross-gcc. The easiest way to do so is to use your distribution's package. The other option is to compile it with the instructions given on the mingw32 web site. Poulpy might provide automatic building of the cross-compiler in the future.
Use bash not dash. The default bourne shell script in Ubuntu is dash This causes some subtle problems in configure scripts that use advanced features of bash. Your /bin/sh should link to /bin/bash. The right thing to do™ would be to fix those cases upstream either by putting #!/bin/bash in the scripts or by using only portable shell constructs.
Disable binfmt support. The Linux kernel is able to run non native binaries, a feature called binfmt. Unfortunately, autoconf does not play well with this feature as it will detect that cross-compiled Windows® binaries can be run and confuse most, if not all, configure scripts.
Wine is used to provide Windows® binfmt backend. It's possible to use Wine and binfmt to get MSVC import libraries (.lib) with Visual's lib.exe, but Poulpy will have to become a little more mature before allowing it.
If the packages you want to compile depend on DirectX® you will
have to install its include files and import libraries from a
DirectX® SDK. I've downloaded the latest one (June 2008) and
adapted it to allow gcc to compile GStreamer's DirectX®
plugins. If you want to compile GStreamer with Poulpy you can
download my
modified version of the SDK from the
Poulpy's website. You will then have to
uncompress somewhere on your filesystem, eg. in
/opt/externals.
[damien@griffith poulpy]$ sudo tar -C /opt/externals -jxvf DirectX-SDK-Poulpy-Edition-0.1.tar.bz2
Poulpy's job breaks down into the following: retrieve the sources of libraries, unpack them, patch them , configure them, build them, and finally package them.
You can either download the latest version of Poulpy on its website and uncompress it or use git to retrieve the cutting edge version:
[damien@griffith src]$ git clone git://git.lespiau.name/poulpy
If you are using externals, some dependencies that
come from an external source such as Microsoft® DirectX® SDK, you
need to tell Poulpy so. This is done by editing the
poulpy.env file and change the
EXTERNALS_ROOT variable.
/opt/externals is the default
value and if you have installed the DirectX® SDK as shown above you
don't need to change anything.
There are a few things Poulpy cannot auto-detect and that
require the user to edit the poulpy/conf/local.conf
file:
The cross-compiler used. There is no way to know which compiler
you want to use with Poulpy so you have to configure it. The
TARGET_ARCH and TARGET_OS
variables should be set accordingly. For instance, the mingw32
compiler in Ubuntu is called
i586-mingw32msvc-gcc, then
TARGET_ARCH is i586 and
TARGET_OS is mingw32msvc.
Sometimes, packagers like to put the vendor name in their cross
compiler prefix, you will have to set
TARGET_VENDOR in those cases.
And a few options the user can temper with:
DL_DIR: directory where the sources tarballs
will be downloaded. It defaults to
$HOME/sources.
TMPDIR: directory where Poulpy will do put
both: the files needed to do its work and the final packages. It
defaults to /opt/poulpy.
The user that runs Poulpy has to be able to create and write
into to the TMPDIR directory. As the default
location is /opt/poulpy,
if you want to use Poulpy with your regular user you will
probably need to create
/opt/poulpy and
chmod 777 it or chose another directory.
BB_NUMBER_THREADS: number of threads BitBake
can launch at the same time. The variable can speed up the build
time dramatically if you have a SMP machine. It defaults to 1.
The first time you run the bitbake command, you may experience a message saying that your system lacks some programs. Poulpy actually checks if your environment have the necessary tools to build packages. You will have to install the needed programs using the packages of your distribution.
When using Poulpy you first have to source
poulpy.env to set up some environment variables:
[damien@griffith poulpy]$ source poulpy.env
Then everything is done through the bitbake command eg. if you want to get the list of packages that you can build:
[damien@griffith poulpy]$ bitbake -s gettext 0:0.17-r0 glib-2.0 0:2.16.3-r0 gst-ffmpeg 0:0.10.4-r0 gst-fluendo-mpegdemux 0:0.10.15-r0 gst-plugins-bad 0:0.10.7-r0 gst-plugins-base 0:0.10.20-r0 gst-plugins-good 0:0.10.8-r0 gst-plugins-ugly 0:0.10.8-r0 gstreamer 0:0.10.20-r0 gstreamer-meta 0:0.10-r0 gstreamer-meta-full 0:0.10-r0 jpeg 0:6b-r0 libogg 0:1.1.3-r0 liboil 0:0.3.15-r0 libpng 0:1.2.26-r0 libtool 0:2.2.4-r0 libtool-cross 0:2.2.4-r0 libtool-native 0:2.2.4-r0 libvorbis 0:1.2.0-r0 libxml2 0:2.6.32-r0 mpeg2dec 0:0.4.1-r0 speex 0:1.2beta3.2-r0 zlib 0:1.2.3-r0
To compile a package just use:
[damien@griffith poulpy]$ bitbake libpng [...] NOTE: Running task 12 of 35 (ID: 9, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_fetch) NOTE: No conf/checksums.ini found, not checking checksums NOTE: Running task 26 of 35 (ID: 8, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_unpack) NOTE: Unpacking /root/sources/libpng-1.2.26.tar.bz2 to /opt/poulpy/work/libpng-1.2.26-r0/ NOTE: Running task 27 of 35 (ID: 7, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_patch) NOTE: Running task 28 of 35 (ID: 5, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_configure) NOTE: Running task 29 of 35 (ID: 6, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_compile) NOTE: Running task 30 of 35 (ID: 10, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_install) NOTE: Running task 31 of 35 (ID: 0, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_package) NOTE: Running task 32 of 35 (ID: 3, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_populate_staging) NOTE: Running task 33 of 35 (ID: 2, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_package_write_tar) NOTE: Running task 34 of 35 (ID: 1, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_package_write) [...] NOTE: Running task 35 of 35 (ID: 4, /root/src/poulpy/poulpy/packages/libpng/libpng_1.2.26.bb, do_build) NOTE: Tasks Summary: Attempted 35 tasks of which 24 didn't need to be rerun and 0 failed.
and after a while you will get a libpng package for windows in the
$TMPDIR/deploy/tar directory.
When listing the available packages with bitabke -s you may have noticed a few packages with meta in their name. These packages are the so called meta packages and are used to build more than a single package; They can build a set of libraries that have a meaning for a maintainer or a programmer that want to distribute a library and its dependencies. Examples of meta packages are given in the next section.
As Poulpy is a fork of OpenEmbedded and Poky you can find a great lot of information on their website. Be sure to read the excellent poky handbook if you want further details on how everything works.
GStreamer is given as an example of using Poulpy for non trivial builds.
GStreamer is a great multimedia framework but it lacks great support for Windows®. Poulpy can help a potential GStreamer windows maintainer to produce binaries for Microsoft®'s OS and thus attract testers and programmers. It's always possible to use the alternate build system based on MSVC project files but the goal of Poulpy is to allow building GStreamer and its dependencies from a linux box an, so let's give it a try!
Poulpy has two meta packages to build Windows® GStreamer
distributions: gstreamer-meta and
gstreamer-meta-full. The first package builds
GStreamer and its main components ie.
gst-plugins-base, gst-plugins-good,
gst-plugins-bad, gst-plugins-ugly
and gst-ffmpeg and a minimal set of dependencies while
the second meta package (-full) builds everything
Poulpy knows about GStreamer.
gstreamer-meta-full looks like a good candidate
to help a GStreamer Windows® maintainer.
The resulting packages are, as always, in the
$TMPDIR/deploy/tar directory.
This appendix gives some details that are too specific to be in a user manual but that still need to be said.
I've cooked a modified version of Microsoft® DirectX® SDK so Poulpy can build GStreamer's DirectX® plugins. However this implies a few hacks listed below:
Fixed some case problems. For instance, you can find
#include <ddraw.h> in some C files but the
file is named DDraw.h on the disk.
Some soft links have been added to be able to link with gcc,
eg. libddraw.a points to
ddraw.lib.
Modification of a few include files. Visual seems tolerant to
multiple occurences of the same typedef,
something that gcc will forcefully reject.
The latest dxerr9.lib (a static library) has been compiled with a very recent C runtime. Mingw32 gcc does not have the needed symbols to link with such a library. I've replaced this lib with the one of old SDK built with MSVC 6.0.
The changes to the official SDK are enough to compile GStreamer's DirectX® plugins, but compiling other DirectX® applications will require more modifications. I'll be pleased to update the SDK if needed.