On Tue, Mar 20, 2012 at 11:05:20AM -0700, Brendan Conoboy wrote:
On 03/20/2012 10:44 AM, drago01 wrote:
>On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboy<blc(a)redhat.com> wrote:
>>Please, please, no. Cross compilation for Fedora cannot and will not ever
>>get a secondary arch to primary. We're talking man-decades of engineering
>>time to solve all the problems. Decades.
>
>Sorry I am not buying that.
Because you have vast experience to the contrary? Look, even x86_64
is topping out on speed and moving to a more-core and
more-systems-per-rack model. Cross compilation solves yesterday's
problem, not tomorrow's. If build speed truly is a fundamental issue
to becoming PA the answer is to harness multiple systems for a
single build, not to use a somewhat faster system to make up for the
speed of a somewhat slower system. Scaling across more cores than
fit in a single SMP Linux environment is the only sensible approach
to future build speedups.
This is a sound observation, but it doesn't apply to Fedora on ARM
unless you can demonstrate a system where rpmbuild scales well across
multiple ARM cores/servers/whatever.
I would suggest -- in order to move the present discussion on -- that
you try using various methods to speed up an ARM build of (eg) glibc.
distcc, some sort of demo cross-compilation, etc. What works, what
doesn't work, what needs more work?
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/