Hi David
Thanks, lots of detail to chew on.
I will work some of it into my blog on installing packages, and very
probably some the rest into a new post on SB2 itself.
Chris
p.s: a Happy Christmas to you, and all members of this list
Zitat von "David Greaves" <david.grea...@jolla.com>:
Warning - lots of detail below.
On 22/12/13 23:29, Marko Koschak wrote:
Hi Matze
On So, 2013-12-22 at 21:50 +0100, christopher.l...@thurweb.ch wrote:
The SDK Build Engine is a little bit more tricky.
Once you SSH in, zypper is available, but if you zypper at that level,
all you are doing is adding stuff to the operating system.
Within this VM is SB2, which is the Build Engine itself. Others on
this mailist are much better qualified than me to tell you more about
it.
If you are familiar with the term chroot (change-root) then you could
thing of SB2 (Scratchbox2) just as an chroot environment running armv7hl
emulated code (through qemu) where you actually build your source rpm
package.
This is pretty much correct but not quite complete.
I mentioned earlier that I used the term "build engine" to describe
the vbox VM
:) Inside there are a number of tools, systems and datasets which
are used to do
the building and sb2 is part of that toolset; it needs a rootfs for
the target
architecture, hence the word 'target' which floats around.
Actually a target is more specific than that - a target represents a
versioned
set of devel headers/libraries/tools.
(Pendantic note : our use of sb2 doesn't yet provide a 'perfect' versioned
target environment but we're working on it)
SB2 comes from the "legacy" of cross-compiling.
I think it's better to say "sb2 avoids the user-side complications of
cross-compiling but benefits from the performance boost."
The problem
with cross-compiling is that you need to tell your compiler not to use
the host (x86) tools and libs for compiling but the equivalent tools and
libs from the target (armv7hl) system. There are multiple approaches to
overcome that. One is to tell the compiler (via e.g. configure,
makefile,...) where to find that stuff or you don't tell the compiler
that (less work to create a makefile that cross-compiles too) but alter
your environment that the compiler "thinks" it is running on the target
(armv7hl) system itself. This is what SB2 actually does. That is very
useful if you want to compile just any "normal" rpm package (from the
linux userland stack) without adapting it to the target architecture.
Yes - sb2 responds like a native ARM system to quite a deep level.
(In detail SB2 is not a "full" chroot system, but it uses fakeroot which
enables SB2 to use host tools for speed up compilation instead of
running arm binaries in slow emulation mode. It's quite some time ago I
used SB2 but I hope I got it right and you got a rough idea... :)
This isn't quite right. It doesn't use fakeroot as such. What it does is
intercept system calls (using LD_PRELOAD) and, very efficiently, translates
filesystem access (using lua if you must know!)
If you're using sb2 and you are in an ARM rootfs then when you access
/usr/bin/myexecutable sb2 looks for the 'right' file to execute.
First it considers that your target is in /srv/mer/target/jolla-arm so it has
the option to look at /srv/mer/target/jolla-arm/usr/bin/myexecutable
which is an
ARM binary that could run using qemu. This would be the fallback location
However it may see that file is in a list of 'accelerated' binaries.
So it now
looks in the 'host' filesystem (usually the host but more sophisticated
solutions are available). So it runs the native
/usr/bin/myexecutable - but it
continues to intercept system calls.
So if myexecutable open()s a /usr/share/mydata then sb2 translates
that path to
/srv/mer/target/jolla-arm/usr/share/mydata
Now, for some special binaries - like gcc, ld etc we don't want to use the
/usr/bin/gcc - we use an x86 version of gcc which emits ARM code.
More docs here:
https://maemo.gitorious.org/scratchbox2/scratchbox2/blobs/raw/2.3_development/docs/SB2_internals_1st_ed_20120425.pdf
Also, you may find some help on setting up your own targets here:
https://wiki.merproject.org/wiki/Platform_SDK_and_SB2
This follows on from:
https://wiki.merproject.org/wiki/Platform_SDK
note that the SDK Build Engine VM is essentially an installation of
the Platform
SDK inside a VM so you don't need another.
So, yes, these are cross-compilers and cross-tools but the important thing is
that the user just sees a very efficient "native" environment.
HTH
David
PS Merry Christmas
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
