On Apr 12, 2010, at 6:35 PM, ext Michael Turney wrote:
Pardon my ignorance, but if the modified filesystem cannot be copied
back to the target,
what problem does sb2 really solve, from a cross-development
environment?
Creating a file system image that can be installed to a device is
really a trivial problem. And there are several solutions for that;
"debootstrap" is maybe one the most widely known tools. Sb2 was not
designed for that.
However, cross-compiling - cross-building, actually - is not a trivial
problem in the linux world, because vast majority of the available OSS
programs have not been designed to be cross-compiled.
In fact, many (most?) software packages require that they are built on
a system that is identical or really close to the target environment.
Such assumption is deeply buried into many software packages and to
the tools, too.
But compiling on a small embedded system is not very feasible.. and
we'd still like to use mainstream packages with minimal modifications.
And that is what the scratchboxes were designed to solve: They are
used to create development environments, that are fairly compatible
with the target environment, so that we don't need to make changes to
hundreds of software packets to make them cross-compilation-aware.
Creating a Linux cross-development environment which looks like a
native one might sound like an easy task to do, but it isn't. I'll try
to explain briefly why, based on our collective experiences on this
field.
Usually people are mistaken to think that only two or three things are
needed for successful cross-building:
a) you need the target file system (which contains libraries, include
files, and also the tools that are needed: "make", autotools, etc)
b) target CPU emulation is needed, and something like the user-mode
Qemu can be used to solve that .
c) a cross-compiler is needed. Alternatively, the compiler can also be
executed within Qemu.
Next, the over-simplified idea about cross-building says that you'll
need to combine all this within e.g chroot, and you're done. Wrong,
unfortunately.
What is usually forgotten, is
d) there are several ways how the development environment can be
detected (for example, the real CPU architecture of the build host),
and various tools use this information for build-time decisions. And
even worse, such details might be recorded to the produced binary
packages.
The result is, quite typically, that unless you pay attention to "d)"
above, your build might go thru without problems, but the results
might be crappy (perl extensions are famous examples of this).
I'm not saying that everything would fail with the simple approach. It
is enough for many packages; but that might be even more dangerous
because it creates a false feeling of safety.
The simple approach works in many cases, because there are tools that
don't care so much about the development environment and are safe to
use. But the opposite is also true: We have seen several tools that
detect the development environment, and then record features of it
somewhere, thinking that the execution environment would be the same.
Once you have a complete distro that was cross-compiled, and some tool
somewhere did something nasty, finding out the problem is not so
pleasant experience anymore ;-)
Another thing that I'm not saying is that the scratchboxes (1 or 2)
would be complete and would solve all such build-related problems.
Very probably they aren't; they just try to offer solutions to those
problems that we have analyzed and fixed.
But we still think that it is easier to maintain this kind of
environment virtualization layers, than to make dozens or hundreds of
changes to various upper-level tools and packages.
I don't mean to sound glib, but sb2 was pushed on me as a solution
to our cross development problem,
not pushed by this mailing list, but by colleagues who had done some
research.
I really appreciate the above input, as it explains a lot of my
frustration, but I have to
wonder how people use sb2 in the wild?
One example is the Maemo SDK+ project, which has used sb2 as a core
component. But it has been developed here, quite close to our sb2
development, so I guess that it don't fall into the "in the wild"
category.
It would be nice to hear about other uses for this, too.
Lauri
_______________________________________________
Scratchbox-devel mailing list
[email protected]
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel
