[fedora-arm] Support for ARMv7, hardware math
omalleys at msu.edu
omalleys at msu.edu
Wed Dec 1 19:37:58 UTC 2010
Quoting Andy Green <andy at warmcat.com>:
> On 12/01/10 18:37, Somebody in the thread at some point said:
>
> Hi -
>
>> I don't disagree with a split, but what concerns me is we don't have
>> enough resources to get F13-ARM out the door, much less two versions of
>> the distro. We don't have enough people nor the hardware to pull it off.
>
> Infrastructure evidently already exists to knock out armv5 packages.
>
>> If you can cross-compile, and knock out 50% of the bugs out in a
>> "pre-build" system before they hit the actual build system. It increases
>
> Several years ago I made my own rpm-based cross-build system similar
> to this. You meet packages like perl, which as part of its build
> process created a "miniperl" that it then ran to complete the build
> process. Except when you build cross, the miniperl executable is an
> ARM executable on an x86_64 box and it can't complete the build
> process.
>
> Most packages are not that tough but there are still enough funnies
> that instead of knocking bugs out in some awesome fast cross
> environment, you are running around discovering and solving
> cross-specific bugs.
yuck. :P
>> the overall speed of development. I am fully aware it isn't going to be
>> simpler then using real hardware, but I was wondering if it would be
>> simpler then trying to get qemu-arm with virtio and the plan9 layer
>> working (i failed the first time).
>
> qemu arm is a dead loss for mass build, it's a fraction of the speed
> of native execution on even a weak arm.
>
>> Distributing a VM "image" with all the build tools set up and everything
>> configured is a lot simpler then setting up a full blown dev environment.
>
> If it was the case that arm will never approach x86 speeds, then
> cross is worth worrying about because it will solve years of speed
> differential by a large effort now.
>
> But that is not the case, fast arm native platforms are already here
> and will only get faster in the future. Cross and arm emulation are
> not the solution and won't become the solution either.
I was looking at today. Today the project has a handful of builders.
How does the project get on track to appear to be a viable solution,
rather then a secondary arch that is 2 releases behind to someone
unfamiliar with the project? What is the easiest way to get there
today?
More information about the arm
mailing list