As the title states, no further effort required. Without disturbing the way native gcc compiles.
Crossdev no longer balks at installing a cross gcc with the same version as the system, so this means not only can it be done the "Funtoo way", but you can also build an identical cross toolchain for maximum compatibility.
The attached ebuild works here with this:
There are two issues. I had this problem on both x86_64 machines I used: https://forums.gentoo.org/viewtopic-p-7823658.html. They refer to this bug report: https://bugs.gentoo.org/show_bug.cgi?id=562460 and it was solved here with this patch: https://bugs.gentoo.org/attachment.cgi?id=414948&action=edit. Note that there isn't ahy code in the binutils-config ebuild to patch, and I didn't try to patch, I simply added those few lines to the file manually. So I don't have any idea how current that patch is, whether you can patch it the proper way. Easy enough though, re-emerge binutils-config then you are ready to build your toolchain. Otherwise gcc would fail building libgcc, "can't find file suffixes", something like that. If you look in
it will mention the real error, can't find libopcodes.so.
The second issue is one for the devs. While this ebuild will work for most armv7a people using --with-fpu=vfpv3-d16 (you can find it on the target with gcc -v), my native system gcc on the target uses a different fpu setting. This caused distcc to decide it's compiles were in error and it refused to use any of them. I solved it by hard-coding my fpu into the local ebuilds here, Since there are a dozen or so possibilities and probably more on the horizon, we need some mechanism to pass that info to the ebuild, perhaps something like the CROSS-COMPILE-OPTS on glibc.
Tests performed: cross toolchains built on two x86_64 machines, re-emerged native gcc on one x86_64 machine and finally ran a few ebuilds using distcc on the target machine. All worked perfectly.