The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Architecture proposals/CoreToolchainSplit
(→Introduction) |
(→cross-kernel-headers) |
||
| Line 21: | Line 21: | ||
== cross-kernel-headers == | == cross-kernel-headers == | ||
| − | This will build kernel headers | + | This will build kernel headers for the target utilizing a linux kernel tarball. |
* creates cross-TARGET-kernel-headers package for x86 (stored in /opt/cross/TARGET/sys-root/) | * creates cross-TARGET-kernel-headers package for x86 (stored in /opt/cross/TARGET/sys-root/) | ||
Latest revision as of 20:08, 16 December 2011
Contents |
[edit] Introduction
I'm thinking of a split of Mer into two OBS projects.
- Mer into a smaller Core (which doesn't have to be self-hosting)
- Mer Toolchain (is self-hosting, doesn't need to be fully bootable on a
machine, but X86-only).
Toolchain would effectively be able to create all the elements for the pieces in Mer Core for any target, such as bootstrapping the glibc/gcc from X86 side into ARM side and not like we have now, where glibc effectively gets injected from ARM side for a cross compiler to be made.
The idea is that for the most part, Toolchain will be provided as a SB2 tools set.
This means that the target will be put into /target in a SB2 build situation. When tools are missing from target, such as perl or autoconf, they'll be taken from Toolchain.
[edit] Packages involved
[edit] cross-kernel-headers
This will build kernel headers for the target utilizing a linux kernel tarball.
- creates cross-TARGET-kernel-headers package for x86 (stored in /opt/cross/TARGET/sys-root/)
- creates kernel-headers-TARGET, exported to the target RPM architecture (read: will be a .rpm) stored in /
[edit] cross-gcc-bootstrap
This will construct a bootstrap gcc, just enough to build glibc. This depends on cross-kernel-headers-TARGET
- creates cross-TARGET-gcc-bootstrap for X86 (stored in /opt/cross/TARGET/)
