[..]
* 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org