jlpoole at pon
Oct 5, 2009, 7:18 PM
Post #1 of 2
(626 views)
Permalink
|
|
Embedded Handbook (5)(b) clarification
|
|
I'd like to get some clarification on the Embedded Handbook,
particularly Chapter 5, subsection 5(b) "Filesystem Setup"
I'm trying to cross-compile on an AMD64 for two Marvel ARM architectures:
a) SheevaPlug which as the ARMv5TE without a numeric coprocessor "softfloat"
http://en.wikipedia.org/wiki/SheevaPlug
b) OpenRD Client which has the ARMv5TE
http://globalscaletechnologies.com/t-openrdcdetails.aspx#features
I previously had problems trying to install and work my cross compiler,
so I simply rebuilt my AMD box and see that the Embedded Handbook has
recently been updated in September, 2009. I had considerable help from
Mike Frysinger back in May and June on IRC, but I lost my chat logs due
to a crash on Windows which I was going to use to refer to and to
reconstruct what I had learned. I haven't had the time to devote to
this project until now and find myself not fully understanding the
instructions.
From
http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml?part=1&chap=5
vvvvvvvvvv
5.b. Filesystem Setup
Cross-compiling a system generally involves two directory trees. The
first is where all development files are normally installed. This is
your sysroot. The other tree is where only your runtime files are
installed. You emerge all of your fun packages into your sysroot
(without trimming down any files), and then either install via binary
packages or copying files by hand all the stuff you need in your runtime
tree.
The common convention is to use your /usr/CTARGET/ tree as your sysroot
as the include/library directories in this tree are already encoded into
the gcc cross-compiler for searching. You could use another directory
and then add custom -I/-L paths to your CPPFLAGS/LDFLAGS, but this has
historically proven to be problematic. Yes, it works most of the time,
but the corner cases are why this method is discouraged. In the embedded
handbook, we'll assume you're using the sysroot as your development ROOT.
For your runtime system, you'll need a much slimmer/trimmed-down setup.
The files you remove from a normal installed package is why this tree is
not suitable for compiling against. If you build binary packages while
installing into your sysroot, then you can use those binary packages in
conjunction with the INSTALL_MASK variable to trim out most things. See
man make.conf for more information.
^^^^^^^^^^
In my case, I have a CTARGET of "arm-softfloat-linux-gnueabi" so
"/usr/arm-softfloat-linux-gnueabi" is my sysroot. My
"arm-softfloat-linux-gnueabi-gcc" compiler knows to look under $CTARGET.
All questions below reference paragraph 3.
Question #1: What does "runtime system" mean? Is that the directory
tree underneath /usr/$CTARGET?
Question #2: I don't understand what you mean by "files you remove from
a normal installed package".
Question #3: "this tree is not suitable..." What tree?
I'm basically lost for the remainder of the paragraph.
When I find I have questions, I will read on past the problem part to
see if I can make sense of it by reading subsequent content.
Unfortunately, this tricky stuff (I apparently broke my previous
environment making assumptions and trying to follow the previous version
of the documentation) and I don't want to make any assumptions which
later cause me to taint, or "hose", my environments.
I do have several questions about subsection 5.c, but will reread that
subsection once I know I'm fully following subsection 5.b.
Thank you for you anticipated help/explanations.
A suggestion. You use an example in the previous chapters, e.g. Chapter
4 "sh4-unknown-linux-gnu". It would be really helpful if subsequent
discussions continued with that example to illustrate the point being
made. This would help provide continuity.
John
--
John Laurence Poole
P.O. Box 6566
Napa CA 94581-6566
Home: 707-265-7572
Office: 650-607-0853
Skype: JohnLPoole My status <skype:JohnLPoole?call>
email: jlpoole [at] pon
|
jlpoole.vcf
