| 1 |
On Sun, May 4, 2008 at 8:46 AM, Mike Frysinger <vapier@g.o> wrote: |
| 2 |
> On Monday 28 April 2008, Dave Bender wrote: |
| 3 |
>> That is currently the solution I use for x86. The drawbacks are |
| 4 |
>> slower compilation performance (cross compilers running on 64 bit |
| 5 |
>> empirically seem faster) and other overhead caused by chrooting. The |
| 6 |
>> approach also does not extend to other architectures like ARM. |
| 7 |
>> Essentially this approach is a lightweight emulation; taken to its |
| 8 |
>> fullest extent you would be running QEMU to build for these other |
| 9 |
>> architectures. |
| 10 |
> |
| 11 |
> you could distcc with the host system. i dont know about "other overhead |
| 12 |
|
| 13 |
That's an interesting suggestion, I'll look into it. |
| 14 |
|
| 15 |
> caused by chrooting" though ... being in a chroot really adds no overhead at |
| 16 |
> all. while you can argue the non-native point if you were targeting |
| 17 |
|
| 18 |
When I use 32bit chroots, some factor slows down file I/O a great |
| 19 |
deal. For example I notice that emerge -uDN takes much |
| 20 |
longer to do in a 32bit chroot. I use mount bind to share the |
| 21 |
/usr/portage directory with the chroot, so I don't think its that |
| 22 |
mechanism. |
| 23 |
All I know is that updating inside the chroot is much slower. |
| 24 |
|
| 25 |
> something non-native, Matthijs point is pretty clear: since you can easily do |
| 26 |
> native, you probably should as over all it will be a much smoother |
| 27 |
> development cycle. |
| 28 |
|
| 29 |
Of course working natively always presents the fewest headaches. What |
| 30 |
bugs me is that it seems so easy from the Embedded Handbook... |
| 31 |
|
| 32 |
> -mike |
| 33 |
> |
| 34 |
-- |
| 35 |
gentoo-embedded@l.g.o mailing list |
Archives