From: Trevor Woerner <twoerner@gmail.com>
To: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Cc: crossgcc@sourceware.org
Subject: [PATCH 2 of 2] docs: Add strategies for assembling root filesystems
Date: Wed, 16 Nov 2011 22:46:00 -0000 [thread overview]
Message-ID: <8bd0d6bdba97ba1f9a80.1321483527@codei7.fpelectronics.com> (raw)
In-Reply-To: <patchbomb.1321483525@codei7.fpelectronics.com>
# HG changeset patch
# User Trevor Woerner <twoerner@gmail.com>
# Date 1321482977 18000
# Node ID 8bd0d6bdba97ba1f9a80be56daf1e6b4161cb9b4
# Parent c1c4d9174fbfd7d76e0e520dc6657cf239a7d718
docs: Add strategies for assembling root filesystems.
Expand the documentation for using a crosstool-NG-generated toolchain for
building a root filesystem for a target device.
Signed-off-by: "Trevor Woerner" <twoerner@gmail.com>
diff -r c1c4d9174fbf -r 8bd0d6bdba97 docs/5 - Using the toolchain.txt
--- a/docs/5 - Using the toolchain.txt Wed Nov 16 16:06:42 2011 -0500
+++ b/docs/5 - Using the toolchain.txt Wed Nov 16 17:36:17 2011 -0500
@@ -21,16 +21,137 @@
make CROSS_COMPILE=your-host-tuple-
and so on...
+
+Assembling a root filesystem /
+_____________________________/
+
+
+Assembling a root filesystem for a target device requires the successive
+building of a set of software packages for the target architecture. Building
+a package potentially requires artifacts which were generated as part of an
+earlier build. Note that not all artifacts which are installed as part of a
+package are desirable on a target's root filesystem (e.g. man/info files,
+include files, etc.). Therefore we must distinguish between a 'staging'
+directory and a 'rootfs' directory.
+
+A 'staging' directory is a location into which we install all the build
+artifacts. We can then point future builds to this location so they can find
+the appropriate header and library files. A 'rootfs' directory is a location
+into which we place only the files we want to have on our target.
+
+There are four schools of thought here:
+
+1) Install directly into the sysroot of the toolchain.
+
+ By default (i.e. if you don't pass any arguments to the tools which
+ would change this behaviour) the toolchain that is built by
+ crosstool-NG will only look in its toolchain directories for system
+ header and library files:
+
+#include "..." search starts here:
+#include <...> search starts here:
+<ct-ng install path>/lib/gcc/<host tuple>/4.5.2/include
+<ct-ng install path>/lib/gcc/<host tuple>/4.5.2/include-fixed
+<ct-ng install path>/lib/gcc/<host tuple>/4.5.2/../../../../<host tuple>/include
+<ct-ng install path>/<host tuple>/sysroot/usr/include
+
+ In other words, the compiler will automagically find headers and
+ libraries without extra flags if they are installed under the
+ toolchain's sysroot directory.
+
+ However, this is bad because the toolchain gets poluted, and can
+ not be re-used.
+
+ $ ./configure --build=<build tuple> --host=<host tuple> \
+ --prefix=/usr --enable-foo-bar...
+ $ make
+ $ make DESTDIR=/<ct-ng install path>/<host tuple>/sysroot install
+
+2) Copy the toolchain's sysroot to the 'staging' area.
+
+ If you start off by copying the toolchain's sysroot directory to your
+ staging area, you can simply proceed to install all your packages'
+ artifacts to the same staging area. You then only need to specify a
+ '--sysroot=<staging area>' option to the compiler of any subsequent
+ builds and all your required header and library files will be found/used.
+
+ This is a viable option, but requires the user to always specify CFLAGS
+ in order to include --sysroot=<staging area>, or requires the use of a
+ wrapper to a few select tools (gcc, ld...) to pass this flag.
+
+ Instead of polluting the toolchain's sysroot you are copying its contents
+ to a new location and polluting the contents in that new location. By
+ specifying the --sysroot option you're effectively abandoning the default
+ sysroot in favour of your own.
+
+ Incidentally this is what buildroot does using a wrapper, when using an
+ external toolchain.
+
+ $ cp -a $(<host tuple>-gcc --your-cflags-except-sysroot -print-sysroot) \
+ /path/to/staging
+ $ ./configure --prefix=/usr --enable-foo-bar... \
+ CC="<host tuple>-gcc --syroot=/path/to/staging" \
+ CXX="<host tuple>-g++ --sysroot=/path/to/staging" \
+ LD="<host tuple>-ld --sysroot=/path/to/staging" \
+ AND_SO_ON=tuple-andsoon --sysroot=/path/to/staging"
+ $ make
+ $ make DESTDIR=/path/to/staging install
+
+3) Use separate staging and sysroot directories.
+
+ In this scenario you use a staging area to install programs, but you do
+ not pre-fill that staging area with the toolchain's sysroot. In this case
+ the compiler will find the system includes and libraries in its sysroot
+ area but you have to pass appropriate CPPFLAGS and LDFLAGS to tell it
+ where to find your headers and libraries from your staging area (or use
+ a wrapper).
+
+ $ CPPFLAGS="-I/path/to/staging/usr/include" \
+ LDFLAGS="-L/path/to/staging/lib -L/path/to/staging/usr/lib" \
+ ./configure --prefix=/usr --enable-foo-bar...
+ $ make
+ $ make DESTDIR=/path/to/staging install
+
+4) A mix of 2) and 3), using carefully crafted union mounts.
+
+ The staging area is a union mount of:
+ - the sysroot as a read-only branch
+ - the real staging area as a read-write branch
+ This also requires passing --sysroot to point to the union mount, but has
+ other advantages, such as allowing per-package staging, and a few more
+ obscure pros. It also has its disadvantages, as it potentially requires
+ non-root users to create union mounts. Additionally, union mounts are not
+ yet mainstream in the Linux kernel, so it requires patching. There is a
+ FUSE-based unionfs implementation, but development is almost stalled,
+ and there are a few gotchas...
+
+ $ (good luck!)
+
+
It is strongly advised not to use the toolchain sysroot directory as an
-install directory for your programs/packages. If you do so, you will not be
-able to use your toolchain for another project. It is even strongly advised
-that your toolchain is chmod-ed to read-only once successfully build, so that
-you don't go polluting your toolchain with your programs/packages' files.
+install directory (i.e. option 1) for your programs/packages. If you do so,
+you will not be able to use your toolchain for another project. It is even
+strongly advised that your toolchain is chmod-ed to read-only once
+successfully install, so that you don't go polluting your toolchain with
+your programs'/packages' files. This can be achieved by selecting the
+"Render the toolchain read-only" from crosstool-NG's "Paths and misc options"
+configuration page.
-Thus, when you build a program/package, install it in a separate directory,
-eg. /your/root. This directory is the /image/ of what would be in the root file
-system of your target, and will contain all that your programs/packages have
-installed.
+Thus, when you build a program/package, install it in a separate, staging,
+directory and let the cross-toolchain continue to use its own, pristine,
+sysroot directory.
+
+When you are done building and want to assemble your rootfs you could simply
+take the full contents of your staging directory and use the 'populate'
+script to add in the necessary files from the sysroot. However, the staging
+area you have created will include lots of build artifacts that you won't
+necessarily want/need on your target. For example: static libraries, header
+files, linking helper files, man/info pages. You'll also need to add various
+configuration files, scripts, and directories to the rootfs so it will boot.
+
+Therefore you'll probably end up creating a separate rootfs directory which
+you will populate from the staging area, necessary extras, and then use
+crosstool-NG's populate script to add the necessary sysroot libraries.
The 'populate' script |
--
For unsubscribe information see http://sourceware.org/lists.html#faq
next prev parent reply other threads:[~2011-11-16 22:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 22:46 [PATCH 0 of 2] documentation update Trevor Woerner
2011-11-16 22:46 ` Trevor Woerner [this message]
2011-11-16 23:29 ` [PATCH 2 of 2] docs: Add strategies for assembling root filesystems Yann E. MORIN
2011-11-17 19:29 ` Thomas Petazzoni
2011-11-17 20:15 ` David Wuertele
2011-11-17 20:32 ` Thomas Petazzoni
2011-11-17 23:05 ` Trevor Woerner
2011-11-16 22:46 ` [PATCH 1 of 2] docs: --target versus --host Trevor Woerner
2011-11-16 23:18 ` Yann E. MORIN
2011-11-16 23:24 ` Trevor Woerner
2011-11-17 19:26 ` Thomas Petazzoni
2011-11-17 21:56 ` Trevor Woerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8bd0d6bdba97ba1f9a80.1321483527@codei7.fpelectronics.com \
--to=twoerner@gmail.com \
--cc=crossgcc@sourceware.org \
--cc=yann.morin.1998@anciens.enib.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).