The Embedded Handbook is awesome and its taught me a lot already, but being new to cross development and I find this portion of the Handbook to be a bit confusing in the following areas: * 5.c Intro: crossdev-wrappers * "We can use these tools for both installing into your development root (sysroot) and into your runtime root. For the latter, simply specify by using the --root option." This contradicts the previous section where the following was stated: "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." To me, this means that we CANNOT "use these tools for both installing into your development root (sysroot) and into your runtime root". But that "these tools can be used to install packages into your SYSROOT". Installing packages into your runtime root is not advisable because it is not suitable for compiling against, because of all that has been trimed. How am I supposed to install packages? CHOST-emerge --root=/usr/CHOST or CHOST-emerge --root=/some/runtime/root In Code Listing 3.2, neither is specified. I found out the hard way that this should never be used. ;) (I stupidly chose to test this with the "tar" package and it overwrote my systems tar.) So this example needs to be changed to reflect the answer to my previous question. In fact, it might be a good idea to incorporate the --root argument into the wrapper scripts so that one doesn't accidently overwrite his build systems files. * "You may want to use the --root-deps=rdeps option to avoid the host dependencies from being pulled into the deptree." This is already included in cross-emerge: > ... > CROSS_CMD=${CROSS_CMD:-emerge --root-deps=rdeps} > ${FAKEROOT} ${CROSS_CMD} "$@" So I think that sentence ought to be removed. * The last paragraph in this section ending with "This becomes obvious after the first few times of doing it." Maybe we could see an example of how to do it. * 5.b Filesystem Setup, I think there should be another section describing in more detail how to create the runtime environment. If I understand correctly, the runtime environment is created from the SYSROOT *after* everything has been installed. If binary packages were built it could be as simple as extracting them into a new folder or even directly onto the embedded device. Anyway, more explanation would be useful. Anway, thanks for the quick fixes and great work in developing such an awesome system/guide! -Kameron
for confusion, a better place really is the mailing list, not bugzilla you're confusing "compiling" and "installing". you install into both, but the runtime is stripped down and you dont compile against that. adding a sanity check to prevent dumb things like --root=$SYSROOT probably wouldnt hurt. the rdeps behavior may change over time. leaving it in the handbook wont hurt. how people create the --root is up to them. they can copy files manually from the sysroot, or create binary packages from the sysroot and strip as they're installed into the root, or something else.
(In reply to comment #1) > for confusion, a better place really is the mailing list, not bugzilla You're right! I'll take my questions there. > you're confusing "compiling" and "installing". you install into both, but the > runtime is stripped down and you dont compile against that. adding a sanity > check to prevent dumb things like --root=$SYSROOT probably wouldnt hurt. I _am_ confusing "compiling" and "installing". But this is because the Handbook does not make this clear. If I follow the handbook's Code Listing 3.2, I'll end up overwriting my build system's pkg0, pkg1, and pkg2. This listing, at least, needs to be changed. I know that is just an example, but it's an incomplete example as --root is not specified. > the rdeps behavior may change over time. leaving it in the handbook wont hurt. > > how people create the --root is up to them. they can copy files manually from > the sysroot, or create binary packages from the sysroot and strip as they're > installed into the root, or something else. >
Oops. I realized after reinstalling that the emerge-wrapper script hadn't created the proper make.conf, because I had already created one. For future note, I shouldn't edit the SYSROOT/etc/make.conf until after running emerge-wrapper. ;-) Closing this bug as invalid. Sorry for the trouble.
