Mailinglist Archive: opensuse-buildservice (214 mails)

< Previous Next >
Re: [opensuse-buildservice] RFC: patches for SB2 integration into OBS for better cross compilation,
[..]
* There has been a prjconf item "SB2install:" added for SB2-needed
dependencies (like Preinstall)

* There has been added a prjconf item "SB2flags:", which, if exists,
will activate SB2 enablement in the 'build' script, and 'getsb2flags'
script to extract this item from prjconf,
https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991
9c6d6388bd#L2L1049

We should find common/generic flags here. Otherwise prjconf's will be
unreadable and cluttered with SB*/Preinstall/foobar ... lets keep it simple
and generic.



* If SB2 is enabled, the following behaviour change will happen:
- If running in chroot mode, it will switch to 'sb2' VM type, and run
a specific init script that sets up SB2, in order to share code
better.
https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b692899
19c6d6388bd#L2R1054

- enter_target will be utilizing SB2 in order to run commands instead
of 'chroot'. At first initialization a SB2 target will be set up and
sessions related to faster cross compilation

- BUILD_TARGET will change to /target and /target will be made

- Packages will get preinstalled/installed into /target, except
SB2install: packages which will get preinstalled into / -- this will
typically be X86 binaries

- A SB2 'target' will be set up, with / as the host and /target as the
sysroot/target,
https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991
9c6d6388bd#L3R152

- SB2flags setting will determine a number of things related to SB2
target configuration:

https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991
9c6d6388bd#L3L55

--toolchain -- the cross compiler from / which should be used for this
build --installmode -- the SB2 mode that should be used to install RPMs
with --defaultmode -- the SB2 mode that should be default (read: to do
builds with) --mappingmethod -- we currently have three mapping methods,
C, Lua and Both, this will get removed eventually and become C by standard
--bootstrap -- don't pass sysroot=/ to the cross compiler, useful for
bootstrapping a target
--qemu -- what QEMU binary should be in use to run target binaries
(qemu-arm, qemu-mips), MUST be a dynamic executable, not static
--infologs -- request that info logs are being made, can be fetched
from /home/abuild/sb2_logs afterwards. Intended to be able to be
picked up like rpmlint.log is right now. These can be used to generate
graphs like http://releases.merproject.org/~carsten/rpm.pdf and with
process accounting, be able to say how much time was wasted running in
QEMU, etc
--debug -- full debug logs

Going away from static and patchelf is good. I'm looking forward to the actual
implementation of multilibs as discussed in latest talks (e.g. wookey).
Adopting this might simplify things even more.


Known issues:

* There is an issue with shell quoting in the chroot wrapper so
RPMIDFMT handling won't work, this is being worked on, but it doesn't
affect general building
* We should be utilizing multiple dependancy trees as proposed by
Daniel instead of SB2install, in order to have a sane way of cross
installing packages
* We can possibly move to a scenario where we have multiple
/opt/cross/ targets with multiple dependancy trees, instead of one
/target
* Work to get SB2 working for Debian packages should be done

Current implementation in Mer:

* We have a qemu-usermode package built
(http://gitweb.merproject.org/gitweb?p=mer-core/qemu-usermode.git;a=tree
) which is dynamically linked, not statically, binfmt_misc not enabled
* We have scratchbox2 package built,
http://gitweb.merproject.org/gitweb?p=mer-core/scratchbox2.git;a=tree
* We have a standard cross compiler built,
http://gitweb.merproject.org/gitweb?p=mer-core/gcc.git;a=blob;f=cross-armv6
l-gcc.spec;h=0062e25b188d514afa8987c4e6db1daed4c2f0ba;hb=HEAD * We have an
injection package, sb2-tools which gets exported with baselibs.conf into
target scheduler,
http://gitweb.merproject.org/gitweb?p=mer-crosshelpers/sb2-tools-template.g
it;a=tree -- this practically is an RPM that contains a X86 root file
system with qemu, cross compiler, sb2, autoconf, perl, etc.
- Should be done in a cleaner way (is quite ugly at the moment) with
multiple dependancy trees. These x86 binaries are -unmodified-, no
patchelf involved.

Good, but no big blob should be used in the long run.

Enabling SB2 is as easy as:

Best regards,
JS
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
References