Uploaded image for project: 'Funtoo Linux'
  1. Funtoo Linux
  2. FL-3787

A crossdev friendly Funtoo gcc ebuild

    Details

    • Type: Bug
    • Status: Backlog
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Story Points:
      4

      Description

      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:

      crossdev --b 2.25-r2 --k 4.9 --l 2.23-r3 --g 5.3.0-r1 -P "-v" -t armv7a-hardfloat-linux-gnueabi
      

      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

      ${WORKDIR}/objdir/<target>/libgcc/config.log
      

      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.

        Attachments

        1. gcc-5.3.0-r1.ebuild
          20 kB
        2. gcc-5.3.0-r1.ebuild.patch
          3 kB
        3. gcc-5.3.0-r1.ebuild.patch.rev4
          5 kB
        4. gcc-5.3.0-r1.ebuild.patch.rev5
          5 kB
        5. gcc-5.3.0-r1.ebuild.patch.rev6
          5 kB
        6. gcc-5.3.0-r1.ebuild.rev1
          20 kB
        7. gcc-5.3.0-r1.ebuild.rev1.patch
          4 kB
        8. gcc-5.3.0-r1.ebuild.rev2
          20 kB
        9. gcc-5.3.0-r1.ebuild.rev2.patch
          4 kB
        10. gcc-5.3.0-r1.ebuild.rev3
          20 kB
        11. gcc-5.3.0-r1.ebuild.rev3.patch
          5 kB
        12. gcc-5.3.0-r1.ebuild.rev4
          20 kB
        13. gcc-5.3.0-r1.ebuild.rev5
          20 kB
        14. gcc-5.3.0-r1.ebuild.rev6
          20 kB

          Issue Links

            Activity

              People

              • Assignee:
                temptorsent temptorsent
                Reporter:
                sputnik sputnik
              • Votes:
                1 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated: