Im expecting my Pi soon. I have an atom based Gentoo box as well. I was wondering if there is possibly a way to get a faster compile time if I offload some of the compiling to another server? Can I compile binaries for an arm processor from a beefy i7?

Up to now I have always compiled right on the system, but now we are seeing some of these lower powered chips (but very cool) appear, doing and emerge system && emerge world can get out of control._________________Drinking from the fountain of knowldege.
Sometimes sipping.
Sometimes gulping.
Always thirsting.

Yes, you can use distcc to do the compilation on a faster system than the target itself. All you need is a cross-compiler on your i7-box (crossdev is just perfect for building one) and distcc there and on your Pi.

as the topic already says, i want to build a gentoo system for my rasperry pi. after trying to use the stage3 tarball, and the experience of waiting 15 minutes for nano to build, i thought it would be better to build a crossdev toolchain for the raspberry pi.

so i ran crossdev -S -v -t armv6j-hardfloat-linux-gnueabi with the newest version of crossdev (unmasked by keyword ~x86)

after that, i set the cflags variable in /usr/armv6j-hardfloat-linux-gnueabi/etc/portage/make.conf to CFLAGS="-O2 -pipe -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -fomit-frame-pointer" and set the make.profile link to /usr/portage/profiles/default/linux/arm/10.0/armv6j and removed ~arm in the ACCEPT_KEYWORDS variable.

now i tried to emerged nano (using armv6j-hardfloat-linux-gnueabi-emerge) and ran into some compiling errors (solved by disabling acl use flag for gettext). after that i thought it would be a good idea to build a complete system with that settings. so i could use my normal pc for cross compiling and i would have the same versions of libraries on my pi and on my pc for compatibility (armv6j-hardfloat-linux-gnueabi-emerge -av @system), but i alway run into strange compiling errors like "cannot run test program while cross compiling" with emerging coreutils. now my question is: is there something wrong in what im doing ? im not very experienced in cross compiling for other architectures than i686 and amd64

but i alway run into strange compiling errors like "cannot run test program while cross compiling" with emerging coreutils. now my question is: is there something wrong in what im doing ? im not very experienced in cross compiling for other architectures than i686 and amd64

me neither but i checked around and it seems that some are more difficult to crosscompile than others. I guess that in your case some checks are failing in configure, i don't know the specific case but you should try to find if you can avoid those checks with something like ./configure --disable

Got mine two days ago. As I don't have a mico USB cable / adapter now, I powered it through GPIO.

Debian and arch work really well, and I am building a new Gentoo environment using QEMU-user : it's a wonderful tool, event if the CPU translation is slow, but I will soon activate distcc to use native cross-compilation in place of emulated CPU compilation._________________Kind regards,
Xavier Miller

My experience so far:
qemu is slower than I expected, probably slower that the raspberry itself on a intel e8500
crossdev is the fastest and it seems easy at the beginning until you start dealing with libtool and .la files and their hardcoded "libdir"
i should try with distcc, but i guess that everything before the compilation will take long

BTW some distro prebuild for the raspberry come with a very "old" kernel that for some reasons can't deal or deal very bad with class10 sd cards. I used to get 4MB/s read/write while now with the updated kernel I get 20/10 MB/s read/write

Ah, indeed, I had problems with Debian on a Sandisk Extreme Pro (45 MB/s). I will try later with a newer kernel.

For the moment, I build everything on an AMD64. The chroot I had cross-compiled had problems with qemu (libgcc_s.so.1 could not be found) and I had problems with the armv6j Gentoo stage 3 (gcc could not run). I mixed this stage 3 with my cross-compiled toolchain and QEMU runs fine with ditscc enabled (running locally, but through a native cross-compiler).

I will also compare the compilation using the raspy, but for now I have an underpowered power supply (300mA) trough GPIO. I will try to find a micro-USB cable / AC Adaptor those days._________________Kind regards,
Xavier Miller

I see there's an /opt/vc which contains all the Broadcom binaries, but how do I integrate it into the system so that everything works?_________________“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010

On a side note whats the lead time on these boards?
Ordered 4 of these today from RS uk. quoting 18 week delivery.
Might be able to sell them on ebay for Christmas?_________________A place for useful technical information

After trying Debian, Arch and a prebuilt Gentoo (which I do not reccomend as it overvolts and oveclocks your Pi.)
Mine was running at 1GHz very briefly.
None of the above was satisfactory so I built a crossdev toolchain following wiki.gentoo.org and the Embedded Handbook. Once I had the toolchain, I tried to emerge @system into an empty root. That fails for lots of reasons.

The next attempt was to use the arm stage3, a USB hard drive and build on the Pi with the help of distcc and the cross toolchain I already had.
It seems to work but I have not got as far as startx yet. The install is ~arm, with a few more recent odds and ends like portage-2.2-0_alpha

I'll host the stripped down stage4 once I have it._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

None of the above was satisfactory so I built a crossdev toolchain following wiki.gentoo.org and the Embedded Handbook. Once I had the toolchain, I tried to emerge @system into an empty root. That fails for lots of reasons.

I had a pretty good success rate overall with the cross-compiler.

It seems like a lot of the packages that don't cross-compile are is @system (or can be built if without acl support), and aside from python (1 hour) and perl (2 hours), they seem to be compilable on the Pi in reasonable time.

So what I did was enable FEATURES="buildpkg" on both the cross-compiler and the Pi, and then synced the packages dir back and forth - getting non-cross-compilable packages onto the cross-compiling machine, and cross-compiled packages onto the Pi.

NeddySeagoon wrote:

a prebuilt Gentoo (which I do not reccomend as it overvolts and oveclocks your Pi.)
Mine was running at 1GHz very briefly

Ouch... overvolting a pretty nasty thing to do without any warning
(from my understanding overclocking won't cause any permanent damage on ARM, though)_________________“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010

[...]
So what I did was enable FEATURES="buildpkg" on both the cross-compiler and the Pi, and then synced the packages dir back and forth - getting non-cross-compilable packages onto the cross-compiling machine, and cross-compiled packages onto the Pi.
[...]

Thanks for the hint - I was still looking for a way to improve compile times._________________read the portage output!
If my answer is too concise, ask for an explanation.

After trying Debian, Arch and a prebuilt Gentoo (which I do not reccomend as it overvolts and oveclocks your Pi.)

This is only half true (well, it's not true, but trying to be polite ;) — Gentoo _doesn't_ „overvolt and overclock your Pi” just like that. Your config _can_ do it. And it even isn't default behaviour in intelminers build…_________________roslin uberlay | grubelek

checking sys/acl.h usability... yes
checking sys/acl.h presence... yes
checking for sys/acl.h... yes
checking for library containing acl_get_file... -lacl
checking for acl_get_file... yes
checking for acl_get_fd... yes
checking for acl_set_file... yes
checking for acl_set_fd... yes
checking for acl_free... yes
checking for acl_from_mode... yes
checking for acl_from_text... yes
checking for acl_delete_def_file... yes
checking for acl_extended_file... yes
checking for acl_delete_fd_np... no
checking for acl_delete_file_np... no
checking for acl_copy_ext_native... no
checking for acl_create_entry_np... no
checking for acl_to_short_text... no
checking for acl_free_text... no
checking for working acl_get_file... cross-compiling
checking for acl... no
checking for getacl... no
checking for aclx_get... no
checking for statacl... no
configure: error: ACLs enabled but support not detected
configure: error: ./configure failed for gettext-tools