Thought I'd follow up on my own post with some specificity on what I'm
imagining:
Brendan Conoboy wrote:
Technical: There must be cross compilers before we can cross compile.
This is actually two packages: Gcc and Binutils. Both are already quite
easy to build such that they use a sys-root. If you're not familiar
with sys-roots, this is path prefix to /. Thus you usually have
something like $sysroot/usr/lib and $sysroot/usr/include. When the
compiler sees #include <stdio.h> it actually reads in
$sysroot/usr/include/stdio.h. Same for -l.
Building a cross binutils requires kernel headers for the target
architecture. Building gcc requires kernel headers and glibc. There
are scripts to solve the initial chicken/egg problem of where to get
that glibc for a new arch. At some point in the future gcc might not
require glibc to build, but we aren't there yet.
The build system must be enhanced to support cross compilation.
This is a really interesting (to me) extension of the build system
requiring enhancements in many areas.
First, there are primitives in Koji that need to be built up such that,
for instance, x86 knows it can cross build arm tools.
Second, the x86 host needs to be able to retrieve and install arm
dependencies in the arm sys-root (arm's glibc, arm's libX11-devel, etc).
Third, a native/cross hybrid environment needs to be setup to facilitate
the common assumptions made by packages. Previous cross compilation
efforts inside my group have spent a lot of time on this. I bet others
have as well
Finally, packages must be modified to support cross compilation.
This is really a one-at-a-time process. It's often a matter of using
relative paths so that #include <header> gets the right header. Or
using headers instead of directly reading from /proc. Every package is
different. Autotools using packages are frequently much easier than non.
Social: As a volunteer effort, it is unreasonable to expect existing
package maintainers to do the work necessary to support cross
compilation. There must be people to take on that responsibility and
work with upstream and package maintainers to integrate the necessary
changes.
I have read the Secondary Architectures proposal and thread with great
interest. While there may be some overlap of interest with cross
compiling, it's not inherently true. Thus, I'd suggest a cross-team who
would generally be responsible for cross-compilation efforts. This
might break down like so:
1. Responsible for parts of the build system dedicated to cross compilation.
2. Maintainers of the cross compilation tools (These would presumably be
rebuilds of gcc and binutils for the cross-targets).
3. Make changes to existing packages in cooperation with the package
maintainer.
4. Be responsible for fixing builds that fail because of cross
compiling, but succeed when natively built.
Anybody whose turf I just suggested stepping on, please chime in!
--
Brendan Conoboy / Red Hat, Inc. / blc@xxxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
