[SailfishDevel] How SB2 works ... was Re: QtContacts available

Tue Dec 24 17:15:25 UTC 2013

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.greaves at 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.lamb at 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
>