On 06/08/2007 09:56 PM, Brendan Conoboy wrote:
[ ... ]
>> 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.
To make koji believe it can build arm on x86 should be no problem. But
how to tell koji to don't do the %test's. We need to do this on rpm level...
> 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).
Now we need to touch yum... I'm sure Seth can hack up that bit of code.
:-) Also mock needs to understand it.
> 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
If I'm picturing myself this process:
# koji build <something>
1) koji finds deps
2) mock uses yum to retrieve deps
2.1) if it sees gcc, it need to get gcc-cross-<target>
2.2) also true for binutils-cross-<target>
2.3) It needs to retrieve the
binaries for the machine running on, else it will not be able to
run it (I'm thinking of autoconf, automake, python, etc.)
3) rpm --rebuild --target <target> <something>-$v-$r.src.rpm
So for the buildsystem I see at least 4 tools we need to touch: rpm,
yum, mock, koji; And eventually setarch.
So far the big picture that came up to my mind; Quick'n'dirty of course...
[ ... ]
>> 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!
At this point the big picture might be the goal, but to reach it, small
steps must be taken:
*) Bring working cross-tools into Fedora
I'm sure this is something more people would be happy to have; Not
only the ArchTeam's.
*) Make rpm --rebuild <target>² do something that _makes sense_ :-)
Eg. Set the $sysroot and set gcc to gcc-<target>, ......
*) THINK: Do we need to touch setarch?
<...> Add more <...>
My few cent. :-)
-of
-------
Footnotes:
²) <target> in this case is a *strange* target for the platform running
the command; eg. arm/ppc/alpha/s390 on x86.
³) <host> in this case is the host running yum (eg. i386, but
downloading arm/ppc/alpha/s390 packages)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
