Initial revision
[openwrt/svn-archive/archive.git] / openwrt / docs / buildroot-documentation.html
3 "">
5 <html xmlns="">
6 <head>
7 <title>Buildroot - Usage and documentation</title>
9 <link rel="stylesheet" type="text/css" href="stylesheet.css" />
10 </head>
12 <body>
13 <div class="main">
14 <div class="titre">
15 <h1>Buildroot</h1>
16 </div>
18 <p>Usage and documentation by Thomas Petazzoni. Contributions from
19 Karsten Kruse, Ned Ludd, Martin Herren.</p>
21 <p><small>Last modification : $Id$</small></p>
23 <ul>
24 <li><a href="#about">About Buildroot</a></li>
25 <li><a href="#download">Obtaining Buildroot</a></li>
26 <li><a href="#using">Using Buildroot</a></li>
27 <li><a href="#custom_targetfs">Customizing the target filesystem</a></li>
28 <li><a href="#custom_busybox">Customizing the Busybox
29 configuration</a></li>
30 <li><a href="#custom_uclibc">Customizing the uClibc
31 configuration</a></li>
32 <li><a href="#buildroot_innards">How Buildroot works</a></li>
33 <li><a href="#using_toolchain">Using the uClibc toolchain</a></li>
34 <li><a href="#toolchain_standalone">Using the uClibc toolchain
35 outside of Buildroot</a></li>
36 <li><a href="#downloaded_packages">Location of downloaded packages</a></li>
37 <li><a href="#add_software">Extending Buildroot with more
38 Software</a></li>
39 <li><a href="#links">Ressources</a></li>
40 </ul>
42 <h2><a name="about" id="about"></a>About Buildroot</h2>
44 <p>Buildroot is a set of Makefiles and patches that allows to easily
45 generate both a cross-compilation toolchain and a root filesystem for your
46 target. The cross-compilation toolchain uses uClibc (<a href=
47 ""></a>), a tiny C standard
48 library.</p>
50 <p>Buildroot is useful mainly for people working with embedded systems.
51 Embedded systems often use processors that are not the regular x86
52 processors everyone is used to have on his PC. It can be PowerPC
53 processors, MIPS processors, ARM processors, etc.</p>
55 <p>A compilation toolchain is the set of tools that allows to
56 compile code for your system. It consists of a compiler (in our
57 case, <code>gcc</code>), binary utils like assembler and linker
58 (in our case, <code>binutils</code>) and a C standard library (for
59 example <a href="">GNU
60 Libc</a>, <a href="">uClibc</a> or <a
61 href="">dietlibc</a>). The system
62 installed on your development station certainly already has a
63 compilation toolchain that you can use to compile application that
64 runs on your system. If you're using a PC, your compilation
65 toolchain runs on an x86 processor and generates code for a x86
66 processor. Under most Linux systems, the compilation toolchain
67 uses the GNU libc as C standard library. This compilation
68 toolchain is called the "host compilation toolchain", and more
69 generally, the machine on which it is running, and on which you're
70 working is called the "host system". The compilation toolchain is
71 provided by your distribution, and Buildroot has nothing to do
72 with it.</p>
74 <p>As said above, the compilation toolchain that comes with your system
75 runs and generates code for the processor of your host system. As your
76 embedded system has a different processor, you need a cross-compilation
77 toolchain: it's a compilation toolchain that runs on your host system but
78 that generates code for your target system (and target processor). For
79 example, if your host system uses x86 and your target system uses ARM, the
80 regular compilation toolchain of your host runs on x86 and generates code
81 for x86, while the cross-compilation toolchain runs on x86 and generates
82 code for ARM.</p>
84 <p>Even if your embedded system uses a x86 processor, you might interested
85 in Buildroot, for two reasons:</p>
87 <ul>
88 <li>The compilation toolchain of your host certainly uses the GNU Libc
89 which is a complete but huge C standard library. Instead of using GNU
90 Libc on your target system, you can use uClibc which is a tiny C standard
91 library. If you want to use this C library, then you need a compilation
92 toolchain to generate binaries linked with it. Buildroot can do it for
93 you.</li>
95 <li>Buildroot automates the building of a root filesystem with all needed
96 tools like busybox. It makes it much easier than doing it by hand.</li>
97 </ul>
99 <p>You might wonder why such a tool is needed when you can compile
100 <code>gcc</code>, <code>binutils</code>, uClibc and all the tools by hand.
101 Of course, doing so is possible. But dealing with all configure options,
102 with all problems of every <code>gcc</code> or <code>binutils</code>
103 version it very time-consuming and uninteresting. Buildroot automates this
104 process through the use of Makefiles, and has a collection of patches for
105 each <code>gcc</code> and <code>binutils</code> version to make them work
106 on most architectures.</p>
108 <h2><a name="download" id="download"></a>Obtaining Buildroot</h2>
110 <p>Buildroot is available as daily CVS snapshots or directly using
111 CVS.</p>
113 <p>The latest snapshot is always available at <a
114 href=""></a>,
115 and previous snapshots are also available at <a
116 href=""></a>.</p>
118 <p>To download Buildroot using CVS, you can simply follow
119 the rules described on the "Accessing CVS"-page (<a href=
120 ""></a>)
121 of the uClibc website (<a href=
122 ""></a>), and download the
123 <code>buildroot</code> CVS module. For the impatient, here's a quick
124 recipe:</p>
126 <pre>
127 $ cvs login
128 $ cvs -z3 co buildroot
129 </pre>
131 <h2><a name="using" id="using"></a>Using Buildroot</h2>
133 <p>Buildroot has a nice configuration tool similar to the one you can find
134 in the Linux Kernel (<a href=
135 ""></a>) or in Busybox
136 (<a href=""></a>). Note that
137 you can run everything as a normal user. There is no need to be root to
138 configure and use Buildroot. The first step is to run the configuration
139 assistant:</p>
141 <pre>
142 $ make menuconfig
143 </pre>
145 <p>For each entry of the configuration tool, you can find associated help
146 that describes the purpose of the entry.</p>
148 <p>Once everything is configured, the configuration tool has generated a
149 <code>.config</code> file that contains the description of your
150 configuration. It will be used by the Makefiles to do what's needed.</p>
152 <p>Let's go:</p>
154 <pre>
155 $ make
156 </pre>
158 <p>This command will download, configure and compile all the selected
159 tools, and finally generate a target filesystem. The target filesystem will
160 be named <code>root_fs_ARCH.EXT</code> where <code>ARCH</code> is your
161 architecture and <code>EXT</code> depends on the type of target filesystem
162 selected in the <code>Target options</code> section of the configuration
163 tool.</p>
165 <h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the
166 target filesystem</h2>
168 <p>There are two ways to customize the resulting target filesystem:</p>
170 <ul>
171 <li>Customize the target filesystem directly, and rebuild the image. The
172 target filesystem is available under <code>build_ARCH/root/</code> where
173 <code>ARCH</code> is the chosen target architecture. You can simply make
174 your changes here, and run make afterwards, which will rebuild the target
175 filesystem image. This method allows to do everything on the target
176 filesystem, but if you decide to completely rebuild your toolchain and
177 tools, these changes will be lost.</li>
179 <li>Customize the target filesystem skeleton, available under
180 <code>target/default/target_skeleton/</code>. You can customize
181 configuration files or other stuff here. However, the full file hierarchy
182 is not yet present, because it's created during the compilation process.
183 So you can't do everything on this target filesystem skeleton, but
184 changes to it remains even you completely rebuild the cross-compilation
185 toolchain and the tools.<br />
186 You can also customize the <code>target/default/device_table.txt</code>
187 file which is used by the tools that generate the target filesystem image
188 to properly set permissions and create device nodes. The
189 <code>target/default/skel.tar.gz</code> file contains the main
190 directories of a root filesystem and there is no obvious reason for which
191 it should be changed. These main directories are in an tarball inside of
192 inside the skeleton because it contains symlinks that would be broken
193 otherwise.</li>
194 </ul>
196 <h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the
197 Busybox configuration</h2>
199 <p>Busybox is very configurable, and you may want to customize it. You can
200 follow these simple steps to do it. It's not an optimal way, but it's
201 simple and it works.</p>
203 <ol>
204 <li>Make a first compilation of buildroot with busybox without trying to
205 customize it.</li>
207 <li>Go into <code>build_ARCH/busybox/</code> and run <code>make
208 menuconfig</code>. The nice configuration tool appears and you can
209 customize everything.</li>
211 <li>Copy the <code>.config</code> file to
212 <code>package/busybox/busybox.config</code> so that your customized
213 configuration will remains even if you remove the cross-compilation
214 toolchain.</li>
216 <li>Run the compilation of buildroot again.</li>
217 </ol>
219 <p>Otherwise, you can simply change the
220 <code>package/busybox/busybox.config</code> file if you know the options
221 you want to change without using the configuration tool.</p>
223 <h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc
224 configuration</h2>
226 <p>Just like <a href="#custom_busybox">BusyBox</a>, <a
227 href="">uClibc</a> offers a lot of
228 configuration options. They allow to select various
229 functionalities, depending on your needs and limitations.</p>
231 <p>The easiest way to modify the configuration of uClibc is to
232 follow these steps :</p>
234 <ol>
236 <li>Make a first compilation of buildroot without trying to
237 customize uClibc.</li>
239 <li>Go into the directory
240 <code>toolchain_build_ARCH/uClibc/</code> and run <code>make
241 menuconfig</code>. The nice configuration assistant, similar to
242 the one used in the Linux Kernel or in Buildroot appears. Make
243 your configuration as appropriate.</li>
245 <li>Copy the <code>.config</code> file to
246 <code>toolchain/uClibc/uClibc.config</code> or
247 <code>toolchain/uClibc/uClibc.config-locale</code>. The former
248 is used if you haven't selected locale support in Buildroot
249 configuration, and the latter is used if you have selected
250 locale support.</li>
252 <li>Run the compilation of Buildroot again</li>
254 </ol>
256 <p>Otherwise, you can simply change
257 <code>toolchain/uClibc/uClibc.config</code> or
258 <code>toolchain/uClibc/uClibc.config-locale</code> without running
259 the configuration assistant.</p>
261 <h2><a name="buildroot_innards" id="buildroot_innards"></a>How Buildroot
262 works</h2>
264 <p>As said above, Buildroot is basically a set of Makefiles that download,
265 configure and compiles software with the correct options. It also includes
266 some patches for various software, mainly the ones involved in the
267 cross-compilation tool chain (<code>gcc</code>, <code>binutils</code> and
268 uClibc).</p>
270 <p>There is basically one Makefile per software, and they are named with
271 the <code>.mk</code> extension. Makefiles are split into three
272 sections:</p>
274 <ul>
275 <li><b>package</b> (in the <code>package/</code> directory) contains the
276 Makefiles and associated files for all user-space tools that Buildroot
277 can compile and add to the target root filesystem. There is one
278 sub-directory per tool.</li>
280 <li><b>toolchain</b> (in the <code>toolchain/</code> directory) contains
281 the Makefiles and associated files for all software related to the
282 cross-compilation toolchain : <code>binutils</code>, <code>ccache</code>,
283 <code>gcc</code>, <code>gdb</code>, <code>kernel-headers</code> and
284 <code>uClibc</code>.</li>
286 <li><b>target</b> (in the <code>target</code> directory) contains the
287 Makefiles and associated files for software related to the generation of
288 the target root filesystem image. Four types of filesystems are supported
289 : ext2, jffs2, cramfs and squashfs. For each of them, there's a
290 sub-directory with the required files. There is also a
291 <code>default/</code> directory that contains the target filesystem
292 skeleton.</li>
293 </ul>
295 <p>Each directory contains at least 3 files :</p>
297 <ul>
298 <li><code></code> is the Makefile that downloads, configures,
299 compiles and installs the software <code>something</code>.</li>
301 <li><code></code> is a part of the configuration tool
302 description file. It describes the option related to the current
303 software.</li>
305 <li><code></code> is a part of Makefile that sets various
306 variables according to the configuration given through the configuration
307 tool. For most tools it simply involves adding the name of the tool to
308 the <code>TARGETS</code> variable.</li>
309 </ul>
311 <p>The main Makefile do the job through the following steps (once the
312 configuration is done):</p>
314 <ol>
315 <li>Create the download directory (<code>dl/</code> by default). This is
316 where the tarballs will be downloaded. It is interesting to know that the
317 tarballs are in this directory because it may be useful to save them
318 somewhere to avoid further downloads.</li>
320 <li>Create the build directory (<code>build_ARCH/</code> by default,
321 where <code>ARCH</code> is your architecture). This is where all
322 user-space tools while be compiled.</li>
324 <li>Create the toolchain build directory
325 (<code>toolchain_build_ARCH/</code> by default, where <code>ARCH</code>
326 is your architecture). This is where the cross compilation toolchain will
327 be compiled.</li>
329 <li>Setup the staging directory (<code>build_ARCH/staging_dir/</code> by
330 default). This is where the cross-compilation toolchain will be
331 installed. If you want to use the same cross-compilation toolchain for
332 other purposes, such as compiling third-party applications, you can add
333 <code>build_ARCH/staging_dir/bin</code> to your PATH, and then use
334 <code>arch-linux-gcc</code> to compile your application. In order to
335 setup this staging directory, it first removes it, and then it creates
336 various subdirectories and symlinks inside it.</li>
338 <li>Create the target directory (<code>build_ARCH/root/</code> by
339 default) and the target filesystem skeleton. This directory will contain
340 the final root filesystem. To setup it up, it first deletes it, then it
341 uncompress the <code>target/default/skel.tar.gz</code> file to create the
342 main subdirectories and symlinks, copies the skeleton available in
343 <code>target/default/target_skeleton</code> and then removes useless
344 <code>CVS/</code> directories.</li>
346 <li>Make the <code>TARGETS</code> dependency. This is where all the job
347 is done : all <code></code> files "subscribe" targets into
348 this global variable, so that the needed tools gets compiled.</li>
349 </ol>
351 <h2><a name="using_toolchain" id="using_toolchain"></a>Using the
352 uClibc toolchain</h2>
354 <p>You may want to compile your own programs or other software
355 that are not packaged in Buildroot. In order to do this, you can
356 use the toolchain that was generated by Buildroot.</p>
358 <p>The toolchain generated by Buildroot by default is located in
359 <code>build_ARCH/staging_dir/</code>. The simplest way to use it
360 is to add <code>build_ARCH/staging_dir/bin/</code> to your PATH
361 environnement variable, and then to use
362 <code>arch-linux-gcc</code>, <code>arch-linux-objdump</code>,
363 <code>arch-linux-ld</code>, etc.</p>
365 <p>For example, you may add the following to your
366 <code>.bashrc</code> (considering you're building for the MIPS
367 architecture and that Buildroot is located in
368 <code>~/buildroot/</code>) :</p>
370 <pre>
371 export PATH=$PATH:~/buildroot/build_mips/bin/
372 </pre>
374 <p>Then you can simply do :</p>
376 <pre>
377 mips-linux-gcc -o foo foo.c
378 </pre>
380 <p><b>Important</b> : do not try to move the toolchain to an other
381 directory, it won't work. There are some hard-coded paths in the
382 <i>gcc</i> configuration. If the default toolchain directory
383 doesn't suit your needs, please refer to the <a
384 href="#toolchain_standalone">Using the uClibc toolchain outside of
385 buildroot</a> section.</p>
387 <h2><a name="toolchain_standalone" id="toolchain_standalone"></a>Using the
388 uClibc toolchain outside of buildroot</h2>
390 <p>By default, the cross-compilation toolchain is generated inside
391 <code>build_ARCH/staging_dir/</code>. But sometimes, it may be useful to
392 install it somewhere else, so that it can be used to compile other programs
393 or by other users. Moving the <code>build_ARCH/staging_dir/</code>
394 directory elsewhere is <b>not possible</b>, because they are some hardcoded
395 paths in the toolchain configuration.</p>
397 <p>If you want to use the generated toolchain for other purposes,
398 you can configure Buildroot to generate it elsewhere using the
399 option of the configuration tool : <code>Build options ->
400 Toolchain and header file location</code>, which defaults to
401 <code>$(BUILD_DIR)/staging_dir/</code>.</p>
403 <h2><a name="downloaded_packages"
404 id="downloaded_packages"></a>Location of downloaded packages</h2>
406 <p>It might be useful to know that the various tarballs that are
407 downloaded by the <i>Makefiles</i> are all stored in the
408 <code>DL_DIR</code> which by default is the <code>dl</code>
409 directory. It's useful for example if you want to keep a complete
410 version of Buildroot which is know to be working with the
411 associated tarballs. This will allow you to regenerate the
412 toolchain and the target filesystem with exactly the same
413 versions.</p>
415 <h2><a name="add_software" id="add_software"></a>Extending Buildroot with
416 more software</h2>
418 <p>This section will only consider the case in which you want to
419 add user-space software.</p>
421 <h3>Package directory</h3>
423 <p>First of all, create a directory under the <code>package</code>
424 directory for your software, for example <code>foo</code>.</p>
426 <h3><code></code> file</h3>
428 <p>Then, create a file named <code></code>. This file
429 will contain the portion of options description related to our
430 <code>foo</code> software that will be used and displayed in the
431 configuration tool. It should basically contain :</p>
433 <pre>
434 config BR2_PACKAGE_FOO
435 bool "foo"
436 default n
437 help
438 This is a comment that explains what foo is.
439 </pre>
441 <p>Of course, you can add other options to configure particular
442 things in your software.</p>
444 <h3><code></code> file</h3>
446 <p>Then, write a <code></code> file. Basically, this is
447 a very short <i>Makefile</i> that adds the name of the software to
448 the list of <code>TARGETS</code> that Buildroot will generate. In
449 fact, the name of the software is the the identifier of the target
450 inside the real <i>Makefile</i> that will do everything (download,
451 compile, install), and that we study below. Back to
452 <code></code>, here is an example :</p>
454 <pre>
455 ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
456 TARGETS+=foo
457 endif
458 </pre>
460 <p>As you can see, this short <i>Makefile</i> simply adds the
461 target <code>foo</code> to the list of targets handled by Buildroot
462 if software <i>foo</i> was selected using the configuration tool.</p>
464 <h3>The real <i>Makefile</i></h3>
466 <p>Finally, here's the hardest part. Create a file named
467 <code></code>. It will contain the <i>Makefile</i> rules that
468 are in charge of downloading, configuring, compiling and installing
469 the software. Below is an example that we will comment
470 afterwards.</p>
472 <pre>
474 2 #
475 3 # foo
476 4 #
478 6 FOO_VERSION:=1.0
479 7 FOO_SOURCE:=less-$(FOO_VERSION).tar.gz
480 8 FOO_SITE:=
482 10 FOO_BINARY:=foo
483 11 FOO_TARGET_BINARY:=usr/bin/foo
484 12
485 13 $(DL_DIR)/$(FOO_SOURCE):
486 14 $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
487 15
488 16 $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
489 17 zcat $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
490 18 touch $(FOO_DIR)/.source
491 19
492 20 $(FOO_DIR)/.configured: $(FOO_DIR)/.source
493 21 (cd $(FOO_DIR); \
496 24 ./configure \
497 25 --target=$(GNU_TARGET_NAME) \
498 26 --host=$(GNU_TARGET_NAME) \
499 27 --build=$(GNU_HOST_NAME) \
500 28 --prefix=/usr \
501 29 --sysconfdir=/etc \
502 30 );
503 31 touch $(FOO_DIR)/.configured;
504 32
505 33 $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
506 34 $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
507 35
509 37 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
510 38 rm -Rf $(TARGET_DIR)/usr/man
511 39
512 40 foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
513 41
514 42 foo-source: $(DL_DIR)/$(FOO_SOURCE)
515 43
516 44 foo-clean:
517 45 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
518 46 -$(MAKE) -C $(FOO_DIR) clean
519 47
520 48 foo-dirclean:
521 49 rm -rf $(FOO_DIR)
522 50
523 </pre>
525 <p>First of all, this <i>Makefile</i> example works for a single
526 binary software. For other software such as libraries or more
527 complex stuff with multiple binaries, it should be adapted. Look at
528 the other <code>*.mk</code> files in the <code>package</code>
529 directory.</p>
531 <p>At lines 6-11, a couple of useful variables are defined :</p>
533 <ul>
535 <li><code>FOO_VERSION</code> : The version of <i>foo</i> that
536 should be downloaded.</li>
538 <li><code>FOO_SOURCE</code> : The name of the tarball of
539 <i>foo</i> on the download website of FTP site. As you can see
540 <code>FOO_VERSION</code> is used.</li>
542 <li><code>FOO_SITE</code> : The HTTP or FTP site from which
543 <i>foo</i> archive is downloaded. It must include the complete
544 path to the directory where <code>FOO_SOURCE</code> can be
545 found.</li>
547 <li><code>FOO_DIR</code> : The directory into which the software
548 will be configured and compiled. Basically, it's a subdirectory
549 of <code>BUILD_DIR</code> which is created upon decompression of
550 the tarball.</li>
552 <li><code>FOO_BINARY</code> : Software binary name. As said
553 previously, this is an example for a single binary software.</li>
555 <li><code>FOO_TARGET_BINARY</code> : The full path of the binary
556 inside the target filesystem.</li>
558 </ul>
560 <p>Lines 13-14 defines a target that downloads the tarball from
561 the remote site to the download directory
562 (<code>DL_DIR</code>).</p>
564 <p>Lines 16-18 defines a target and associated rules that
565 uncompress the downloaded tarball. As you can see, this target
566 depends on the tarball file, so that the previous target (line
567 13-14) is called before executing the rules of the current
568 target. Uncompressing is followed by <i>touching</i> a hidden file
569 to mark the software has having been uncompressed. This trick is
570 used everywhere in Buildroot <i>Makefile</i> to split steps
571 (download, uncompress, configure, compile, install) while still
572 having correct dependencies.</p>
574 <p>Lines 20-31 defines a target and associated rules that
575 configures the software. It depends on the previous target (the
576 hidden <code>.source</code> file) so that we are sure the software has
577 been uncompressed. In order to configure it, it basically runs the
578 well-known <code>./configure</code>script. As we may be doing
579 cross-compilation, <code>target</code>, <code>host</code> and
580 <code>build</code> arguments are given. The prefix is also set to
581 <code>/usr</code>, not because the software will be installed in
582 <code>/usr</code> on your host system, but in the target
583 filesystem. Finally it creates a <code>.configured</code> file to
584 mark the software as configured.</p>
586 <p>Lines 33-34 defines a target and a rule that compiles the
587 software. This target will create the binary file in the
588 compilation directory, and depends on the software being already
589 configured (hence the reference to the <code>.configured</code>
590 file). It basically runs <code>make</code> inside the source
591 directory.</p>
593 <p>Lines 36-38 defines a target and associated rules that install
594 the software inside the target filesystem. It depends on the
595 binary file in the source directory, to make sure the software has
596 been compiled. It uses the <code>install</code> target of the
597 software <code>Makefile</code> by passing a <code>prefix</code>
598 argument, so that the <code>Makefile</code> doesn't try to install
599 the software inside host <code>/usr</code> but inside target
600 <code>/usr</code>. After the installation, the
601 <code>/usr/man</code> directory inside the target filesystem is
602 removed to save space.</p>
604 <p>Line 40 defines the main target of the software, the one
605 referenced in the <code></code> file. This targets
606 should first of all depends on the dependecies of the software (in
607 our example, <i>uclibc</i> and <i>ncurses</i>), and then to the
608 final binary. This last dependency will call all previous
609 dependencies in the right order. </p>
611 <p>Line 42 defines a simple target that only downloads the code
612 source. This is not used during normal operation of Buildroot, but
613 might be useful.</p>
615 <p>Lignes 44-46 define a simple target to clean the software build
616 by calling the <i>Makefiles</i> with the appropriate option.</p>
618 <p>Lines 48-49 define a simple target to completely remove the
619 directory in which the software was uncompressed, configured and
620 compiled.</p>
622 <h3>Conclusion</h3>
624 <p>As you can see, adding a software to buildroot is simply a
625 matter of writing a <i>Makefile</i> using an already existing
626 example and to modify it according to the compilation process of
627 the software.</p>
629 <p>If you package software that might be useful for other persons,
630 don't forget to send a patch to Buildroot developers !</p>
632 <h2><a name="links" id="links"></a>Ressources</h2>
634 <p>To learn more about Buildroot you can visit these
635 websites:</p>
637 <ul>
640 </ul>
642 </div>
643 </body>
644 </html>