|
|
@ -4,7 +4,7 @@ |
|
|
|
|
|
|
|
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml"> |
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml"> |
|
|
|
<head> |
|
|
|
<head> |
|
|
|
<title>Buildroot - Usage and documentation</title> |
|
|
|
<title>OpenWrt Buildroot - Usage and documentation</title> |
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> |
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> |
|
|
|
<link rel="stylesheet" type="text/css" href="stylesheet.css" /> |
|
|
|
<link rel="stylesheet" type="text/css" href="stylesheet.css" /> |
|
|
|
</head> |
|
|
|
</head> |
|
|
@ -12,46 +12,41 @@ |
|
|
|
<body> |
|
|
|
<body> |
|
|
|
<div class="main"> |
|
|
|
<div class="main"> |
|
|
|
<div class="titre"> |
|
|
|
<div class="titre"> |
|
|
|
<h1>Buildroot</h1> |
|
|
|
<h1>OpenWrt Buildroot</h1> |
|
|
|
</div> |
|
|
|
</div> |
|
|
|
|
|
|
|
|
|
|
|
<p>Usage and documentation by Thomas Petazzoni. Contributions from |
|
|
|
<p>Usage and documentation by Felix Fietkau, based on uClibc Buildroot |
|
|
|
Karsten Kruse, Ned Ludd, Martin Herren.</p> |
|
|
|
documentation by Thomas Petazzoni. Contributions from Karsten Kruse, |
|
|
|
|
|
|
|
Ned Ludd, Martin Herren.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p><small>Last modification : $Id$</small></p> |
|
|
|
<p><small>Last modification : $Id$</small></p> |
|
|
|
|
|
|
|
|
|
|
|
<ul> |
|
|
|
<ul> |
|
|
|
<li><a href="#about">About Buildroot</a></li> |
|
|
|
<li><a href="#about">About OpenWrt Buildroot</a></li> |
|
|
|
<li><a href="#download">Obtaining Buildroot</a></li> |
|
|
|
<li><a href="#download">Obtaining OpenWrt Buildroot</a></li> |
|
|
|
<li><a href="#using">Using Buildroot</a></li> |
|
|
|
<li><a href="#using">Using OpenWrt Buildroot</a></li> |
|
|
|
<li><a href="#custom_targetfs">Customizing the target filesystem</a></li> |
|
|
|
<li><a href="#custom_targetfs">Customizing the target filesystem</a></li> |
|
|
|
<li><a href="#custom_busybox">Customizing the Busybox |
|
|
|
<li><a href="#custom_busybox">Customizing the Busybox |
|
|
|
configuration</a></li> |
|
|
|
configuration</a></li> |
|
|
|
<li><a href="#custom_uclibc">Customizing the uClibc |
|
|
|
<li><a href="#custom_uclibc">Customizing the uClibc |
|
|
|
configuration</a></li> |
|
|
|
configuration</a></li> |
|
|
|
<li><a href="#buildroot_innards">How Buildroot works</a></li> |
|
|
|
<li><a href="#buildroot_innards">How OpenWrt Buildroot works</a></li> |
|
|
|
<li><a href="#using_toolchain">Using the uClibc toolchain</a></li> |
|
|
|
<li><a href="#using_toolchain">Using the uClibc toolchain</a></li> |
|
|
|
<li><a href="#toolchain_standalone">Using the uClibc toolchain |
|
|
|
<li><a href="#toolchain_standalone">Using the uClibc toolchain |
|
|
|
outside of Buildroot</a></li> |
|
|
|
outside of Buildroot</a></li> |
|
|
|
<li><a href="#downloaded_packages">Location of downloaded packages</a></li> |
|
|
|
<li><a href="#downloaded_packages">Location of downloaded packages</a></li> |
|
|
|
<li><a href="#add_software">Extending Buildroot with more |
|
|
|
<li><a href="#add_software">Extending OpenWrt with more Software</a></li> |
|
|
|
Software</a></li> |
|
|
|
|
|
|
|
<li><a href="#links">Ressources</a></li> |
|
|
|
<li><a href="#links">Ressources</a></li> |
|
|
|
</ul> |
|
|
|
</ul> |
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="about" id="about"></a>About Buildroot</h2> |
|
|
|
<h2><a name="about" id="about"></a>About OpenWrt Buildroot</h2> |
|
|
|
|
|
|
|
|
|
|
|
<p>Buildroot is a set of Makefiles and patches that allows to easily |
|
|
|
<p>OpenWrt Buildroot is a set of Makefiles and patches that allows to easily |
|
|
|
generate both a cross-compilation toolchain and a root filesystem for your |
|
|
|
generate both a cross-compilation toolchain and a root filesystem for your |
|
|
|
target. The cross-compilation toolchain uses uClibc (<a href= |
|
|
|
Wireless Router. The cross-compilation toolchain uses uClibc (<a href= |
|
|
|
"http://www.uclibc.org/">http://www.uclibc.org/</a>), a tiny C standard |
|
|
|
"http://www.uclibc.org/">http://www.uclibc.org/</a>), a tiny C standard |
|
|
|
library.</p> |
|
|
|
library.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>Buildroot is useful mainly for people working with embedded systems. |
|
|
|
|
|
|
|
Embedded systems often use processors that are not the regular x86 |
|
|
|
|
|
|
|
processors everyone is used to have on his PC. It can be PowerPC |
|
|
|
|
|
|
|
processors, MIPS processors, ARM processors, etc.</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>A compilation toolchain is the set of tools that allows to |
|
|
|
<p>A compilation toolchain is the set of tools that allows to |
|
|
|
compile code for your system. It consists of a compiler (in our |
|
|
|
compile code for your system. It consists of a compiler (in our |
|
|
|
case, <code>gcc</code>), binary utils like assembler and linker |
|
|
|
case, <code>gcc</code>), binary utils like assembler and linker |
|
|
@ -68,7 +63,7 @@ |
|
|
|
toolchain is called the "host compilation toolchain", and more |
|
|
|
toolchain is called the "host compilation toolchain", and more |
|
|
|
generally, the machine on which it is running, and on which you're |
|
|
|
generally, the machine on which it is running, and on which you're |
|
|
|
working is called the "host system". The compilation toolchain is |
|
|
|
working is called the "host system". The compilation toolchain is |
|
|
|
provided by your distribution, and Buildroot has nothing to do |
|
|
|
provided by your distribution, and OpenWrt Buildroot has nothing to do |
|
|
|
with it.</p> |
|
|
|
with it.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>As said above, the compilation toolchain that comes with your system |
|
|
|
<p>As said above, the compilation toolchain that comes with your system |
|
|
@ -76,66 +71,34 @@ |
|
|
|
embedded system has a different processor, you need a cross-compilation |
|
|
|
embedded system has a different processor, you need a cross-compilation |
|
|
|
toolchain: it's a compilation toolchain that runs on your host system but |
|
|
|
toolchain: it's a compilation toolchain that runs on your host system but |
|
|
|
that generates code for your target system (and target processor). For |
|
|
|
that generates code for your target system (and target processor). For |
|
|
|
example, if your host system uses x86 and your target system uses ARM, the |
|
|
|
example, if your host system uses x86 and your target system uses MIPS, the |
|
|
|
regular compilation toolchain of your host runs on x86 and generates code |
|
|
|
regular compilation toolchain of your host runs on x86 and generates code |
|
|
|
for x86, while the cross-compilation toolchain runs on x86 and generates |
|
|
|
for x86, while the cross-compilation toolchain runs on x86 and generates |
|
|
|
code for ARM.</p> |
|
|
|
code for MIPS.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>Even if your embedded system uses a x86 processor, you might interested |
|
|
|
|
|
|
|
in Buildroot, for two reasons:</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>The compilation toolchain of your host certainly uses the GNU Libc |
|
|
|
|
|
|
|
which is a complete but huge C standard library. Instead of using GNU |
|
|
|
|
|
|
|
Libc on your target system, you can use uClibc which is a tiny C standard |
|
|
|
|
|
|
|
library. If you want to use this C library, then you need a compilation |
|
|
|
|
|
|
|
toolchain to generate binaries linked with it. Buildroot can do it for |
|
|
|
|
|
|
|
you.</li> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<li>Buildroot automates the building of a root filesystem with all needed |
|
|
|
|
|
|
|
tools like busybox. It makes it much easier than doing it by hand.</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>You might wonder why such a tool is needed when you can compile |
|
|
|
<p>You might wonder why such a tool is needed when you can compile |
|
|
|
<code>gcc</code>, <code>binutils</code>, uClibc and all the tools by hand. |
|
|
|
<code>gcc</code>, <code>binutils</code>, uClibc and all the tools by hand. |
|
|
|
Of course, doing so is possible. But dealing with all configure options, |
|
|
|
Of course, doing so is possible. But dealing with all configure options, |
|
|
|
with all problems of every <code>gcc</code> or <code>binutils</code> |
|
|
|
with all problems of every <code>gcc</code> or <code>binutils</code> |
|
|
|
version it very time-consuming and uninteresting. Buildroot automates this |
|
|
|
version it very time-consuming and uninteresting. OpenWrt Buildroot automates this |
|
|
|
process through the use of Makefiles, and has a collection of patches for |
|
|
|
process through the use of Makefiles, and has a collection of patches for |
|
|
|
each <code>gcc</code> and <code>binutils</code> version to make them work |
|
|
|
each <code>gcc</code> and <code>binutils</code> version to make them work |
|
|
|
on most architectures.</p> |
|
|
|
on the MIPS architecture of most Broadcom based Wireless Routers.</p> |
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="download" id="download"></a>Obtaining Buildroot</h2> |
|
|
|
<h2><a name="download" id="download"></a>Obtaining OpenWrt Buildroot</h2> |
|
|
|
|
|
|
|
|
|
|
|
<p>Buildroot is available as daily CVS snapshots or directly using |
|
|
|
<p>OpenWrt Buildroot is currently available as experimental snapshots</p> |
|
|
|
CVS.</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>The latest snapshot is always available at <a |
|
|
|
<p>The latest snapshot is always available at <a |
|
|
|
href="http://uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2">http://uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2</a>, |
|
|
|
href="http://openwrt.org/downloads/experimental/">http://openwrt.org/downloads/experimental/</a>, |
|
|
|
and previous snapshots are also available at <a |
|
|
|
|
|
|
|
href="http://uclibc.org/downloads/snapshots/">http://uclibc.org/downloads/snapshots/</a>.</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>To download Buildroot using CVS, you can simply follow |
|
|
|
|
|
|
|
the rules described on the "Accessing CVS"-page (<a href= |
|
|
|
|
|
|
|
"http://www.uclibc.org/cvs_anon.html">http://www.uclibc.org/cvs_anon.html</a>) |
|
|
|
|
|
|
|
of the uClibc website (<a href= |
|
|
|
|
|
|
|
"http://www.uclibc.org">http://www.uclibc.org</a>), and download the |
|
|
|
|
|
|
|
<code>buildroot</code> CVS module. For the impatient, here's a quick |
|
|
|
|
|
|
|
recipe:</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<pre> |
|
|
|
|
|
|
|
$ cvs -d:pserver:anonymous@uclibc.org:/var/cvs login |
|
|
|
|
|
|
|
$ cvs -z3 -d:pserver:anonymous@uclibc.org:/var/cvs co buildroot |
|
|
|
|
|
|
|
</pre> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="using" id="using"></a>Using Buildroot</h2> |
|
|
|
<h2><a name="using" id="using"></a>Using OpenWrt Buildroot</h2> |
|
|
|
|
|
|
|
|
|
|
|
<p>Buildroot has a nice configuration tool similar to the one you can find |
|
|
|
<p>OpenWrt Buildroot has a nice configuration tool similar to the one you can find |
|
|
|
in the Linux Kernel (<a href= |
|
|
|
in the Linux Kernel (<a href="http://www.kernel.org/">http://www.kernel.org/</a>) |
|
|
|
"http://www.kernel.org/">http://www.kernel.org/</a>) or in Busybox |
|
|
|
or in Busybox (<a href="http://www.busybox.org/">http://www.busybox.org/</a>). |
|
|
|
(<a href="http://www.busybox.org/">http://www.busybox.org/</a>). Note that |
|
|
|
Note that you can run everything as a normal user. There is no need to be root to |
|
|
|
you can run everything as a normal user. There is no need to be root to |
|
|
|
configure and use the Buildroot. The first step is to run the configuration |
|
|
|
configure and use Buildroot. The first step is to run the configuration |
|
|
|
|
|
|
|
assistant:</p> |
|
|
|
assistant:</p> |
|
|
|
|
|
|
|
|
|
|
|
<pre> |
|
|
|
<pre> |
|
|
@ -156,12 +119,24 @@ |
|
|
|
</pre> |
|
|
|
</pre> |
|
|
|
|
|
|
|
|
|
|
|
<p>This command will download, configure and compile all the selected |
|
|
|
<p>This command will download, configure and compile all the selected |
|
|
|
tools, and finally generate a target filesystem. The target filesystem will |
|
|
|
tools, and finally generate target firmware images and additional packages |
|
|
|
be named <code>root_fs_ARCH.EXT</code> where <code>ARCH</code> is your |
|
|
|
(depending on your selections in <code>make menuconfig</code>. |
|
|
|
architecture and <code>EXT</code> depends on the type of target filesystem |
|
|
|
All the target files can be found in the <code>bin/</code> subdirectory. |
|
|
|
selected in the <code>Target options</code> section of the configuration |
|
|
|
You can compile firmware images containing two different filesystem types: |
|
|
|
tool.</p> |
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>jffs2</li> |
|
|
|
|
|
|
|
<li>squashfs</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
<p><code>jffs2</code> contains a writable root filesystem, which will expand to |
|
|
|
|
|
|
|
the size of your flash image. Note that you if you use the generic firmware |
|
|
|
|
|
|
|
Image, you need to pick the right image for your Flash size, because of different |
|
|
|
|
|
|
|
eraseblock sizes.</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p><code>squashfs</code> contains a read-only root filesystem using a modified |
|
|
|
|
|
|
|
<code>squashfs</code> filesystem with LZMA compression. When booting it, you can |
|
|
|
|
|
|
|
create a writable second filesystem, which will contain your modifications to |
|
|
|
|
|
|
|
the root filesystem, including the packages you install. |
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the |
|
|
|
<h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the |
|
|
|
target filesystem</h2> |
|
|
|
target filesystem</h2> |
|
|
|
|
|
|
|
|
|
|
@ -170,55 +145,27 @@ |
|
|
|
<ul> |
|
|
|
<ul> |
|
|
|
<li>Customize the target filesystem directly, and rebuild the image. The |
|
|
|
<li>Customize the target filesystem directly, and rebuild the image. The |
|
|
|
target filesystem is available under <code>build_ARCH/root/</code> where |
|
|
|
target filesystem is available under <code>build_ARCH/root/</code> where |
|
|
|
<code>ARCH</code> is the chosen target architecture. You can simply make |
|
|
|
<code>ARCH</code> is the chosen target architecture, usually mipsel. |
|
|
|
your changes here, and run make afterwards, which will rebuild the target |
|
|
|
You can simply make your changes here, and run make target_install afterwards, |
|
|
|
filesystem image. This method allows to do everything on the target |
|
|
|
which will rebuild the target filesystem image. This method allows to do |
|
|
|
filesystem, but if you decide to completely rebuild your toolchain and |
|
|
|
everything on the target filesystem, but if you decide to rebuild your toolchain, |
|
|
|
tools, these changes will be lost.</li> |
|
|
|
tools or packages, these changes will be lost.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li>Customize the target filesystem skeleton, available under |
|
|
|
<li>Customize the target filesystem skeleton, available under |
|
|
|
<code>target/default/target_skeleton/</code>. You can customize |
|
|
|
<code>target/default/target_skeleton/</code>. You can customize |
|
|
|
configuration files or other stuff here. However, the full file hierarchy |
|
|
|
configuration files or other stuff here. However, the full file hierarchy |
|
|
|
is not yet present, because it's created during the compilation process. |
|
|
|
is not yet present, because it's created during the compilation process. |
|
|
|
So you can't do everything on this target filesystem skeleton, but |
|
|
|
So you can't do everything on this target filesystem skeleton, but |
|
|
|
changes to it remains even you completely rebuild the cross-compilation |
|
|
|
changes to it remains even when you completely rebuild the cross-compilation |
|
|
|
toolchain and the tools.<br /> |
|
|
|
toolchain and the tools.<br /> |
|
|
|
You can also customize the <code>target/default/device_table.txt</code> |
|
|
|
|
|
|
|
file which is used by the tools that generate the target filesystem image |
|
|
|
|
|
|
|
to properly set permissions and create device nodes. The |
|
|
|
|
|
|
|
<code>target/default/skel.tar.gz</code> file contains the main |
|
|
|
|
|
|
|
directories of a root filesystem and there is no obvious reason for which |
|
|
|
|
|
|
|
it should be changed. These main directories are in an tarball inside of |
|
|
|
|
|
|
|
inside the skeleton because it contains symlinks that would be broken |
|
|
|
|
|
|
|
otherwise.</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
</ul> |
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the |
|
|
|
<h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the |
|
|
|
Busybox configuration</h2> |
|
|
|
Busybox configuration</h2> |
|
|
|
|
|
|
|
|
|
|
|
<p>Busybox is very configurable, and you may want to customize it. You can |
|
|
|
<p>Busybox is very configurable, and you may want to customize it. |
|
|
|
follow these simple steps to do it. It's not an optimal way, but it's |
|
|
|
Its configuration is completely integrated into the main menuconfig system. |
|
|
|
simple and it works.</p> |
|
|
|
You can find it under "OpenWrt Package Selection" => "Busybox Configuration"</p> |
|
|
|
|
|
|
|
|
|
|
|
<ol> |
|
|
|
|
|
|
|
<li>Make a first compilation of buildroot with busybox without trying to |
|
|
|
|
|
|
|
customize it.</li> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<li>Go into <code>build_ARCH/busybox/</code> and run <code>make |
|
|
|
|
|
|
|
menuconfig</code>. The nice configuration tool appears and you can |
|
|
|
|
|
|
|
customize everything.</li> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<li>Copy the <code>.config</code> file to |
|
|
|
|
|
|
|
<code>package/busybox/busybox.config</code> so that your customized |
|
|
|
|
|
|
|
configuration will remains even if you remove the cross-compilation |
|
|
|
|
|
|
|
toolchain.</li> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<li>Run the compilation of buildroot again.</li> |
|
|
|
|
|
|
|
</ol> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>Otherwise, you can simply change the |
|
|
|
|
|
|
|
<code>package/busybox/busybox.config</code> file if you know the options |
|
|
|
|
|
|
|
you want to change without using the configuration tool.</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc |
|
|
|
<h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc |
|
|
|
configuration</h2> |
|
|
|
configuration</h2> |
|
|
@ -239,17 +186,17 @@ |
|
|
|
<li>Go into the directory |
|
|
|
<li>Go into the directory |
|
|
|
<code>toolchain_build_ARCH/uClibc/</code> and run <code>make |
|
|
|
<code>toolchain_build_ARCH/uClibc/</code> and run <code>make |
|
|
|
menuconfig</code>. The nice configuration assistant, similar to |
|
|
|
menuconfig</code>. The nice configuration assistant, similar to |
|
|
|
the one used in the Linux Kernel or in Buildroot appears. Make |
|
|
|
the one used in the Linux Kernel appears. Make |
|
|
|
your configuration as appropriate.</li> |
|
|
|
your configuration as appropriate.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li>Copy the <code>.config</code> file to |
|
|
|
<li>Copy the <code>.config</code> file to |
|
|
|
<code>toolchain/uClibc/uClibc.config</code> or |
|
|
|
<code>toolchain/uClibc/uClibc.config</code> or |
|
|
|
<code>toolchain/uClibc/uClibc.config-locale</code>. The former |
|
|
|
<code>toolchain/uClibc/uClibc.config-locale</code>. The former |
|
|
|
is used if you haven't selected locale support in Buildroot |
|
|
|
is used if you haven't selected locale support in the Buildroot |
|
|
|
configuration, and the latter is used if you have selected |
|
|
|
configuration, and the latter is used if you have selected |
|
|
|
locale support.</li> |
|
|
|
locale support.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li>Run the compilation of Buildroot again</li> |
|
|
|
<li>Run the compilation again</li> |
|
|
|
|
|
|
|
|
|
|
|
</ol> |
|
|
|
</ol> |
|
|
|
|
|
|
|
|
|
|
@ -258,18 +205,17 @@ |
|
|
|
<code>toolchain/uClibc/uClibc.config-locale</code> without running |
|
|
|
<code>toolchain/uClibc/uClibc.config-locale</code> without running |
|
|
|
the configuration assistant.</p> |
|
|
|
the configuration assistant.</p> |
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="buildroot_innards" id="buildroot_innards"></a>How Buildroot |
|
|
|
<h2><a name="buildroot_innards" id="buildroot_innards"></a>How OpenWrt Buildroot |
|
|
|
works</h2> |
|
|
|
works</h2> |
|
|
|
|
|
|
|
|
|
|
|
<p>As said above, Buildroot is basically a set of Makefiles that download, |
|
|
|
<p>As said above, OpenWrt is basically a set of Makefiles that download, |
|
|
|
configure and compiles software with the correct options. It also includes |
|
|
|
configure and compiles software with the correct options. It also includes |
|
|
|
some patches for various software, mainly the ones involved in the |
|
|
|
some patches for various software, mainly the ones involved in the |
|
|
|
cross-compilation tool chain (<code>gcc</code>, <code>binutils</code> and |
|
|
|
cross-compilation tool chain (<code>gcc</code>, <code>binutils</code> and |
|
|
|
uClibc).</p> |
|
|
|
uClibc).</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>There is basically one Makefile per software, and they are named with |
|
|
|
<p>There is basically one Makefile per software, and they are named <code>Makefile</code>. |
|
|
|
the <code>.mk</code> extension. Makefiles are split into three |
|
|
|
Makefiles are split into three sections:</p> |
|
|
|
sections:</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<ul> |
|
|
|
<ul> |
|
|
|
<li><b>package</b> (in the <code>package/</code> directory) contains the |
|
|
|
<li><b>package</b> (in the <code>package/</code> directory) contains the |
|
|
@ -286,26 +232,18 @@ |
|
|
|
<li><b>target</b> (in the <code>target</code> directory) contains the |
|
|
|
<li><b>target</b> (in the <code>target</code> directory) contains the |
|
|
|
Makefiles and associated files for software related to the generation of |
|
|
|
Makefiles and associated files for software related to the generation of |
|
|
|
the target root filesystem image. Four types of filesystems are supported |
|
|
|
the target root filesystem image. Four types of filesystems are supported |
|
|
|
: ext2, jffs2, cramfs and squashfs. For each of them, there's a |
|
|
|
: jffs2 and squashfs. |
|
|
|
sub-directory with the required files. There is also a |
|
|
|
|
|
|
|
<code>default/</code> directory that contains the target filesystem |
|
|
|
|
|
|
|
skeleton.</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
</ul> |
|
|
|
|
|
|
|
|
|
|
|
<p>Each directory contains at least 3 files :</p> |
|
|
|
<p>Each directory contains at least 3 files :</p> |
|
|
|
|
|
|
|
|
|
|
|
<ul> |
|
|
|
<ul> |
|
|
|
<li><code>something.mk</code> is the Makefile that downloads, configures, |
|
|
|
<li><code>Makefile</code> is the Makefile that downloads, configures, |
|
|
|
compiles and installs the software <code>something</code>.</li> |
|
|
|
compiles and installs the software <code>something</code>.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li><code>Config.in</code> is a part of the configuration tool |
|
|
|
<li><code>Config.in</code> is a part of the configuration tool |
|
|
|
description file. It describes the option related to the current |
|
|
|
description file. It describes the option related to the current |
|
|
|
software.</li> |
|
|
|
software.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li><code>Makefile.in</code> is a part of Makefile that sets various |
|
|
|
|
|
|
|
variables according to the configuration given through the configuration |
|
|
|
|
|
|
|
tool. For most tools it simply involves adding the name of the tool to |
|
|
|
|
|
|
|
the <code>TARGETS</code> variable.</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
</ul> |
|
|
|
|
|
|
|
|
|
|
|
<p>The main Makefile do the job through the following steps (once the |
|
|
|
<p>The main Makefile do the job through the following steps (once the |
|
|
@ -338,24 +276,22 @@ |
|
|
|
<li>Create the target directory (<code>build_ARCH/root/</code> by |
|
|
|
<li>Create the target directory (<code>build_ARCH/root/</code> by |
|
|
|
default) and the target filesystem skeleton. This directory will contain |
|
|
|
default) and the target filesystem skeleton. This directory will contain |
|
|
|
the final root filesystem. To setup it up, it first deletes it, then it |
|
|
|
the final root filesystem. To setup it up, it first deletes it, then it |
|
|
|
uncompress the <code>target/default/skel.tar.gz</code> file to create the |
|
|
|
copies the skeleton available in <code>target/default/target_skeleton</code> |
|
|
|
main subdirectories and symlinks, copies the skeleton available in |
|
|
|
and then removes useless <code>CVS/</code> directories.</li> |
|
|
|
<code>target/default/target_skeleton</code> and then removes useless |
|
|
|
|
|
|
|
<code>CVS/</code> directories.</li> |
|
|
|
<li>Call the <code>prepare</code>, <code>compile</code> and <code>install</code> |
|
|
|
|
|
|
|
targets for the subdirectories <code>toolchain</code>, <code>package</code> |
|
|
|
<li>Make the <code>TARGETS</code> dependency. This is where all the job |
|
|
|
and <code>target</code></li> |
|
|
|
is done : all <code>Makefile.in</code> files "subscribe" targets into |
|
|
|
|
|
|
|
this global variable, so that the needed tools gets compiled.</li> |
|
|
|
|
|
|
|
</ol> |
|
|
|
</ol> |
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="using_toolchain" id="using_toolchain"></a>Using the |
|
|
|
<h2><a name="using_toolchain" id="using_toolchain"></a>Using the |
|
|
|
uClibc toolchain</h2> |
|
|
|
uClibc toolchain</h2> |
|
|
|
|
|
|
|
|
|
|
|
<p>You may want to compile your own programs or other software |
|
|
|
<p>You may want to compile your own programs or other software |
|
|
|
that are not packaged in Buildroot. In order to do this, you can |
|
|
|
that are not packaged in OpenWrt. In order to do this, you can |
|
|
|
use the toolchain that was generated by Buildroot.</p> |
|
|
|
use the toolchain that was generated by the Buildroot.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>The toolchain generated by Buildroot by default is located in |
|
|
|
<p>The toolchain generated by the Buildroot by default is located in |
|
|
|
<code>build_ARCH/staging_dir/</code>. The simplest way to use it |
|
|
|
<code>build_ARCH/staging_dir/</code>. The simplest way to use it |
|
|
|
is to add <code>build_ARCH/staging_dir/bin/</code> to your PATH |
|
|
|
is to add <code>build_ARCH/staging_dir/bin/</code> to your PATH |
|
|
|
environnement variable, and then to use |
|
|
|
environnement variable, and then to use |
|
|
@ -396,7 +332,7 @@ mips-linux-gcc -o foo foo.c |
|
|
|
|
|
|
|
|
|
|
|
<p>If you want to use the generated toolchain for other purposes, |
|
|
|
<p>If you want to use the generated toolchain for other purposes, |
|
|
|
you can configure Buildroot to generate it elsewhere using the |
|
|
|
you can configure Buildroot to generate it elsewhere using the |
|
|
|
option of the configuration tool : <code>Build options -> |
|
|
|
option of the configuration tool : <code>Build options -> |
|
|
|
Toolchain and header file location</code>, which defaults to |
|
|
|
Toolchain and header file location</code>, which defaults to |
|
|
|
<code>$(BUILD_DIR)/staging_dir/</code>.</p> |
|
|
|
<code>$(BUILD_DIR)/staging_dir/</code>.</p> |
|
|
|
|
|
|
|
|
|
|
@ -412,7 +348,7 @@ mips-linux-gcc -o foo foo.c |
|
|
|
toolchain and the target filesystem with exactly the same |
|
|
|
toolchain and the target filesystem with exactly the same |
|
|
|
versions.</p> |
|
|
|
versions.</p> |
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="add_software" id="add_software"></a>Extending Buildroot with |
|
|
|
<h2><a name="add_software" id="add_software"></a>Extending OpenWrt with |
|
|
|
more software</h2> |
|
|
|
more software</h2> |
|
|
|
|
|
|
|
|
|
|
|
<p>This section will only consider the case in which you want to |
|
|
|
<p>This section will only consider the case in which you want to |
|
|
@ -432,7 +368,7 @@ mips-linux-gcc -o foo foo.c |
|
|
|
|
|
|
|
|
|
|
|
<pre> |
|
|
|
<pre> |
|
|
|
config BR2_PACKAGE_FOO |
|
|
|
config BR2_PACKAGE_FOO |
|
|
|
bool "foo" |
|
|
|
tristate "foo" |
|
|
|
default n |
|
|
|
default n |
|
|
|
help |
|
|
|
help |
|
|
|
This is a comment that explains what foo is. |
|
|
|
This is a comment that explains what foo is. |
|
|
@ -441,56 +377,77 @@ config BR2_PACKAGE_FOO |
|
|
|
<p>Of course, you can add other options to configure particular |
|
|
|
<p>Of course, you can add other options to configure particular |
|
|
|
things in your software.</p> |
|
|
|
things in your software.</p> |
|
|
|
|
|
|
|
|
|
|
|
<h3><code>Makefile.in</code> file</h3> |
|
|
|
<h3><code>Makefile</code> in the package directory</h3> |
|
|
|
|
|
|
|
|
|
|
|
<p>Then, write a <code>Makefile.in</code> file. Basically, this is |
|
|
|
<p>To add your package to the build process, you need to edit |
|
|
|
a very short <i>Makefile</i> that adds the name of the software to |
|
|
|
the Makefile in the <code>package/</code> directory. Locate the |
|
|
|
the list of <code>TARGETS</code> that Buildroot will generate. In |
|
|
|
lines that look like the following:</p> |
|
|
|
fact, the name of the software is the the identifier of the target |
|
|
|
|
|
|
|
inside the real <i>Makefile</i> that will do everything (download, |
|
|
|
|
|
|
|
compile, install), and that we study below. Back to |
|
|
|
|
|
|
|
<code>Makefile.in</code>, here is an example :</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<pre> |
|
|
|
<pre> |
|
|
|
ifeq ($(strip $(BR2_PACKAGE_FOO)),y) |
|
|
|
package-$(BR2_PACKAGE_FOO) += foo |
|
|
|
TARGETS+=foo |
|
|
|
|
|
|
|
endif |
|
|
|
|
|
|
|
</pre> |
|
|
|
</pre> |
|
|
|
|
|
|
|
|
|
|
|
<p>As you can see, this short <i>Makefile</i> simply adds the |
|
|
|
<p>As you can see, this short line simply adds the target |
|
|
|
target <code>foo</code> to the list of targets handled by Buildroot |
|
|
|
<code>foo</code> to the list of targets handled by OpenWrt Buildroot.</p> |
|
|
|
if software <i>foo</i> was selected using the configuration tool.</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>In addition to the default dependencies, you make your package |
|
|
|
|
|
|
|
depend on another package (e.g. a library) by adding a line: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<pre> |
|
|
|
|
|
|
|
foo-compile: bar-compile |
|
|
|
|
|
|
|
</pre> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>The <i>.control</i> file</h3> |
|
|
|
|
|
|
|
<p>Additionally, you need to create a control file which contains |
|
|
|
|
|
|
|
information about your package, readable by the <i>ipkg</i> package |
|
|
|
|
|
|
|
utility.</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>The file looks like this</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<pre> |
|
|
|
|
|
|
|
1 Package: foo |
|
|
|
|
|
|
|
2 Priority: optional |
|
|
|
|
|
|
|
3 Section: net |
|
|
|
|
|
|
|
4 Maintainer: Foo Software <foo@foosoftware.com> |
|
|
|
|
|
|
|
5 Source: http://foosoftware.com |
|
|
|
|
|
|
|
6 Description: Your Package Description |
|
|
|
|
|
|
|
</pre> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>You can skip the usual <code>Version:</code> and <code>Architecture</code> |
|
|
|
|
|
|
|
fields, as they will be generated by the <code>make-ipkg-dir.sh</code> script |
|
|
|
|
|
|
|
called from your Makefile</p> |
|
|
|
|
|
|
|
|
|
|
|
<h3>The real <i>Makefile</i></h3> |
|
|
|
<h3>The real <i>Makefile</i></h3> |
|
|
|
|
|
|
|
|
|
|
|
<p>Finally, here's the hardest part. Create a file named |
|
|
|
<p>Finally, here's the hardest part. Create a file named |
|
|
|
<code>foo.mk</code>. It will contain the <i>Makefile</i> rules that |
|
|
|
<code>Makefile</code>. It will contain the <i>Makefile</i> rules that |
|
|
|
are in charge of downloading, configuring, compiling and installing |
|
|
|
are in charge of downloading, configuring, compiling and installing |
|
|
|
the software. Below is an example that we will comment |
|
|
|
the software. Below is an example that we will comment |
|
|
|
afterwards.</p> |
|
|
|
afterwards.</p> |
|
|
|
|
|
|
|
|
|
|
|
<pre> |
|
|
|
<pre> |
|
|
|
1 ############################################################# |
|
|
|
1 ############################################################# |
|
|
|
2 # |
|
|
|
2 # foo |
|
|
|
3 # foo |
|
|
|
3 ############################################################# |
|
|
|
4 # |
|
|
|
4 PKG_NAME:=foo |
|
|
|
5 ############################################################# |
|
|
|
5 PKG_VERSION:=1.0 |
|
|
|
6 FOO_VERSION:=1.0 |
|
|
|
6 PKG_RELEASE:=1 |
|
|
|
7 FOO_SOURCE:=less-$(FOO_VERSION).tar.gz |
|
|
|
7 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz |
|
|
|
8 FOO_SITE:=http://www.foosoftware.org/downloads |
|
|
|
8 PKG_SITE:=http://www.foosoftware.org/downloads |
|
|
|
9 FOO_DIR:=$(BUILD_DIR)/less-$(FOO_VERSION) |
|
|
|
9 PKG_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION) |
|
|
|
10 FOO_BINARY:=foo |
|
|
|
10 PKG_IPK:=$(PACKAGE_DIR)/$(PKG_NAME)_$(PKG_VERSION)-$(PKG_RELEASE)_$(ARCH).ipk |
|
|
|
11 FOO_TARGET_BINARY:=usr/bin/foo |
|
|
|
11 PKG_IPK_DIR:=$(PKG_DIR)/ipkg |
|
|
|
12 |
|
|
|
12 |
|
|
|
13 $(DL_DIR)/$(FOO_SOURCE): |
|
|
|
13 $(DL_DIR)/$(PKG_SOURCE): |
|
|
|
14 $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE) |
|
|
|
14 $(WGET) -P $(DL_DIR) $(PKG_SITE)/$(PKG_SOURCE) |
|
|
|
15 |
|
|
|
15 |
|
|
|
16 $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE) |
|
|
|
16 $(PKG_DIR)/.source: $(DL_DIR)/$(PKG_SOURCE) |
|
|
|
17 zcat $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) - |
|
|
|
17 zcat $(DL_DIR)/$(PKG_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) - |
|
|
|
18 touch $(FOO_DIR)/.source |
|
|
|
18 touch $(PKG_DIR)/.source |
|
|
|
19 |
|
|
|
19 |
|
|
|
20 $(FOO_DIR)/.configured: $(FOO_DIR)/.source |
|
|
|
20 $(PKG_DIR)/.configured: $(PKG_DIR)/.source |
|
|
|
21 (cd $(FOO_DIR); \ |
|
|
|
21 (cd $(PKG_DIR); \ |
|
|
|
22 $(TARGET_CONFIGURE_OPTS) \ |
|
|
|
22 $(TARGET_CONFIGURE_OPTS) \ |
|
|
|
23 CFLAGS="$(TARGET_CFLAGS)" \ |
|
|
|
23 CFLAGS="$(TARGET_CFLAGS)" \ |
|
|
|
24 ./configure \ |
|
|
|
24 ./configure \ |
|
|
@ -500,60 +457,60 @@ endif |
|
|
|
28 --prefix=/usr \ |
|
|
|
28 --prefix=/usr \ |
|
|
|
29 --sysconfdir=/etc \ |
|
|
|
29 --sysconfdir=/etc \ |
|
|
|
30 ); |
|
|
|
30 ); |
|
|
|
31 touch $(FOO_DIR)/.configured; |
|
|
|
31 touch $(PKG_DIR)/.configured; |
|
|
|
32 |
|
|
|
32 |
|
|
|
33 $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured |
|
|
|
33 $(PKG_DIR)/foo $(PKG_DIR)/.configured |
|
|
|
34 $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR) |
|
|
|
34 $(MAKE) CC=$(TARGET_CC) -C $(PKG_DIR) |
|
|
|
35 |
|
|
|
35 |
|
|
|
36 $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY) |
|
|
|
36 $(PKG_IPK): $(PKG_DIR)/$(PKG_BINARY) |
|
|
|
37 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install |
|
|
|
37 $(SCRIPT_DIR)/make-ipkg-dir.sh $(PKG_IPK_DIR) $(PKG_NAME).control $(PKG_VERSION)-$(PKG_RELEASE) $(ARCH) |
|
|
|
38 rm -Rf $(TARGET_DIR)/usr/man |
|
|
|
38 $(MAKE) prefix=$(PKG_IPK_DIR)/usr -C $(PKG_DIR) install |
|
|
|
39 |
|
|
|
39 rm -Rf $(PKG_IPK_DIR)/usr/man |
|
|
|
40 foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY) |
|
|
|
40 $(IPKG_BUILD) $(PKG_IPK_DIR) $(PACKAGE_DIR) |
|
|
|
41 |
|
|
|
41 |
|
|
|
42 foo-source: $(DL_DIR)/$(FOO_SOURCE) |
|
|
|
42 $(IPKG_STATE_DIR)/info/$(PKG_NAME).list: $(PKG_IPK) |
|
|
|
43 |
|
|
|
43 $(IPKG) install $(PKG_IPK) |
|
|
|
44 foo-clean: |
|
|
|
44 |
|
|
|
45 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall |
|
|
|
45 prepare: $(PKG_DIR)/.source |
|
|
|
46 -$(MAKE) -C $(FOO_DIR) clean |
|
|
|
46 compile: $(PKG_IPK) |
|
|
|
47 |
|
|
|
47 install: $(IPKG_STATE_DIR)/info/$(PKG_NAME).list |
|
|
|
48 foo-dirclean: |
|
|
|
48 clean: |
|
|
|
49 rm -rf $(FOO_DIR) |
|
|
|
49 rm -rf $(PKG_DIR) |
|
|
|
50 |
|
|
|
50 rm -f $(PKG_IPK) |
|
|
|
</pre> |
|
|
|
</pre> |
|
|
|
|
|
|
|
|
|
|
|
<p>First of all, this <i>Makefile</i> example works for a single |
|
|
|
<p>First of all, this <i>Makefile</i> example works for a single |
|
|
|
binary software. For other software such as libraries or more |
|
|
|
binary software. For other software such as libraries or more |
|
|
|
complex stuff with multiple binaries, it should be adapted. Look at |
|
|
|
complex stuff with multiple binaries, it should be adapted. Look at |
|
|
|
the other <code>*.mk</code> files in the <code>package</code> |
|
|
|
the other <code>Makefile</code> files in the <code>package</code> |
|
|
|
directory.</p> |
|
|
|
directory.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>At lines 6-11, a couple of useful variables are defined :</p> |
|
|
|
<p>At lines 4-11, a couple of useful variables are defined :</p> |
|
|
|
|
|
|
|
|
|
|
|
<ul> |
|
|
|
<ul> |
|
|
|
|
|
|
|
<li><code>PKG_NAME</code> : The package name, e.g. <i>foo</i>.</li> |
|
|
|
<li><code>FOO_VERSION</code> : The version of <i>foo</i> that |
|
|
|
|
|
|
|
|
|
|
|
<li><code>PKG_VERSION</code> : The version of the package that |
|
|
|
should be downloaded.</li> |
|
|
|
should be downloaded.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li><code>FOO_SOURCE</code> : The name of the tarball of |
|
|
|
<li><code>PKG_RELEASE</code> : The release number that will be |
|
|
|
<i>foo</i> on the download website of FTP site. As you can see |
|
|
|
appended to the version number of your <i>ipkg</i> package. |
|
|
|
<code>FOO_VERSION</code> is used.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li><code>PKG_SOURCE</code> : The name of the tarball of |
|
|
|
|
|
|
|
your package on the download website of FTP site. As you can see |
|
|
|
|
|
|
|
<code>PKG_NAME</code> and <code>PKG_VERSION</code> are used.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li><code>FOO_SITE</code> : The HTTP or FTP site from which |
|
|
|
<li><code>PKG_SITE</code> : The HTTP or FTP site from which |
|
|
|
<i>foo</i> archive is downloaded. It must include the complete |
|
|
|
the archive is downloaded. It must include the complete |
|
|
|
path to the directory where <code>FOO_SOURCE</code> can be |
|
|
|
path to the directory where <code>FOO_SOURCE</code> can be |
|
|
|
found.</li> |
|
|
|
found.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li><code>FOO_DIR</code> : The directory into which the software |
|
|
|
<li><code>PKG_DIR</code> : The directory into which the software |
|
|
|
will be configured and compiled. Basically, it's a subdirectory |
|
|
|
will be configured and compiled. Basically, it's a subdirectory |
|
|
|
of <code>BUILD_DIR</code> which is created upon decompression of |
|
|
|
of <code>BUILD_DIR</code> which is created upon decompression of |
|
|
|
the tarball.</li> |
|
|
|
the tarball.</li> |
|
|
|
|
|
|
|
|
|
|
|
<li><code>FOO_BINARY</code> : Software binary name. As said |
|
|
|
<li><code>PKG_IPK</code> : The resulting <i>ipkg</i> pacakge |
|
|
|
previously, this is an example for a single binary software.</li> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<li><code>FOO_TARGET_BINARY</code> : The full path of the binary |
|
|
|
|
|
|
|
inside the target filesystem.</li> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</ul> |
|
|
|
</ul> |
|
|
|
|
|
|
|
|
|
|
@ -590,34 +547,33 @@ endif |
|
|
|
file). It basically runs <code>make</code> inside the source |
|
|
|
file). It basically runs <code>make</code> inside the source |
|
|
|
directory.</p> |
|
|
|
directory.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>Lines 36-38 defines a target and associated rules that install |
|
|
|
<p>Lines 36-40 defines a target and associated rules that create |
|
|
|
the software inside the target filesystem. It depends on the |
|
|
|
the <i>ipkg</i> package which can optionally be embedded into |
|
|
|
binary file in the source directory, to make sure the software has |
|
|
|
the resulting firmware image. It depends on the binary file in |
|
|
|
been compiled. It uses the <code>install</code> target of the |
|
|
|
the source directory, to make sure the software has been compiled. |
|
|
|
|
|
|
|
It uses the make-ipkg-dir.sh script, which will create the ipkg |
|
|
|
|
|
|
|
build directory for your package, copy your control file into |
|
|
|
|
|
|
|
that directory and add version and architecture information. |
|
|
|
|
|
|
|
Then it calls the <code>install</code> target of the |
|
|
|
software <code>Makefile</code> by passing a <code>prefix</code> |
|
|
|
software <code>Makefile</code> by passing a <code>prefix</code> |
|
|
|
argument, so that the <code>Makefile</code> doesn't try to install |
|
|
|
argument, so that the <code>Makefile</code> doesn't try to install |
|
|
|
the software inside host <code>/usr</code> but inside target |
|
|
|
the software inside host <code>/usr</code> but inside target |
|
|
|
<code>/usr</code>. After the installation, the |
|
|
|
<code>/usr</code>. After the installation, the |
|
|
|
<code>/usr/man</code> directory inside the target filesystem is |
|
|
|
<code>/usr/man</code> directory inside the target filesystem is |
|
|
|
removed to save space.</p> |
|
|
|
removed to save space. |
|
|
|
|
|
|
|
Finally <code>IPKG_BUILD</code> is called to create the package.</p> |
|
|
|
<p>Line 40 defines the main target of the software, the one |
|
|
|
|
|
|
|
referenced in the <code>Makefile.in</code> file. This targets |
|
|
|
|
|
|
|
should first of all depends on the dependecies of the software (in |
|
|
|
|
|
|
|
our example, <i>uclibc</i> and <i>ncurses</i>), and then to the |
|
|
|
|
|
|
|
final binary. This last dependency will call all previous |
|
|
|
|
|
|
|
dependencies in the right order. </p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>Line 42 defines a simple target that only downloads the code |
|
|
|
|
|
|
|
source. This is not used during normal operation of Buildroot, but |
|
|
|
|
|
|
|
might be useful.</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>Lignes 44-46 define a simple target to clean the software build |
|
|
|
<p>Line 42 and 43 define the installation target of your package, |
|
|
|
by calling the <i>Makefiles</i> with the appropriate option.</p> |
|
|
|
which will embed the software into the target filesystem.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>Lines 48-49 define a simple target to completely remove the |
|
|
|
<p>Lines 45-50 define the main targets that the Makefile in the |
|
|
|
directory in which the software was uncompressed, configured and |
|
|
|
<code>package</code> dir calls. |
|
|
|
compiled.</p> |
|
|
|
<ul> |
|
|
|
|
|
|
|
<li><code>prepare</code> : Download and unpack the source</li> |
|
|
|
|
|
|
|
<li><code>compile</code> : Compile the source and create the package</li> |
|
|
|
|
|
|
|
<li><code>install</code> : Embed the package into the target filesystem</li> |
|
|
|
|
|
|
|
<li><code>clean</code> : Remove all the files created by the build process</li> |
|
|
|
|
|
|
|
</ul></p> |
|
|
|
|
|
|
|
|
|
|
|
<h3>Conclusion</h3> |
|
|
|
<h3>Conclusion</h3> |
|
|
|
|
|
|
|
|
|
|
@ -627,17 +583,12 @@ endif |
|
|
|
the software.</p> |
|
|
|
the software.</p> |
|
|
|
|
|
|
|
|
|
|
|
<p>If you package software that might be useful for other persons, |
|
|
|
<p>If you package software that might be useful for other persons, |
|
|
|
don't forget to send a patch to Buildroot developers !</p> |
|
|
|
don't forget to send a patch to OpenWrt developers !</p> |
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="links" id="links"></a>Ressources</h2> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>To learn more about Buildroot you can visit these |
|
|
|
<h2><a name="links" id="links"></a>Resources</h2> |
|
|
|
websites:</p> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<ul> |
|
|
|
<p>To learn more about OpenWrt Buildroot you can visit this |
|
|
|
<li><a href="http://www.uclibc.org/">http://www.uclibc.org/</a></li> |
|
|
|
website: <a href="http://openwrt.org/">http://openwrt.org/</a></p> |
|
|
|
<li><a href="http://www.busybox.net/">http://www.busybox.net/</a></li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</div> |
|
|
|
</div> |
|
|
|
</body> |
|
|
|
</body> |
|
|
|