Sparc64 support

Adrian Chadd adrian.chadd at gmail.com
Mon Aug 10 05:11:46 UTC 2015


On 9 August 2015 at 21:34, Jordan Hubbard <jordanhubbard at me.com> wrote:
>
>> On Aug 9, 2015, at 8:48 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
>>
>> What's missing is someone funding / finishing the push to external
>> toolchain support for all platforms.
>
> Does someone have that condensed down to a set of bullet points?  Which platforms are mandatory and which are optional?  Is the task considered done when one can do:
>
> # cd /usr/src
> # make buildworld buildkernel USE_EXT_TOOLCHAIN=yes EXT_TOOLCHAIN_PORT=gcc-4.9 (or whatever the suitable incantation is?)
>
> Does it have to work for multiple values of “external toolchain”?  Is it a safe assumption to just say that “port install FOO” will be a sufficient prerequisite and /usr/local/bin/cc is all one needs to reference as the right compiler driver (for the C stuff obviously).
>
> If anyone is going to fund anything, they will want a very specific set of deliverables to fund, since it’s otherwise kind of a blank check with a completely arbitrary outcome.

It's supposed to be (for mips):

pkg install mips-gcc mips-xtoolchain
make ... CROSS_TOOLCHAIN=mips-gcc ...

.. however there are loose ends to fix that prevent that from working
out of the box.

There's also some way involving "X" variables that one can use to
point tools and such at non-system-default versions of things, but
it's not nicely wrapped up as CROSS_TOOLCHAIN is, and I don't believe
it's authoritatively documented (eg in a manpage, or share/examples/.)
I get slightly different versions of slightly different things from
different people each time I ask.

>> What's also missing a little bit here is the tier-1-ness of the
>> external toolchain support by the people using/developing other
>> toolchains.
>
> Not sure what that means?

The clang folk (eg dim) didn't use the external toolchain stuff the
last time I checked. They would create a new branch and import clang
into freebsd in it, or just extract it over the top of a freebsd
checkout. Ie, the folk that would be the #1 testers and consumers of
this stuff don't use it. I don't know if they still do it - we should
ask.

>> It's basically there. There are some rough edges, but since the
>> compiler-developer people aren't using it and the non-x86-building
>> people aren't being forced to use it, the development inches along
>> very slowly.
>
> Again, maybe you could qualify just what that means.  I don’t know what moving parts are even really being described here.  My life is clang / LLVM and has been for a very long time - I don’t even know what gcc is anymore. :)

See above. :)

>> If you'd like to erm, "rush" this along, we should actively start the
>> "deorbit gcc-4.2 by freebsd-11" and "disconnect gcc-4.2 from the -head
>> build" movement now, get those bits done, and start arm-twisting to
>> get the last bits finished.
>
> If gcc 4.2 de-orbits then that means that clang / LLVM can take its place as the “default toolchain” in base and any other value of GCC (which?) comes from ports?

Right - for those ports that don't currently 'work' stable on
clang/llvm, they'd just fail to build unless one defined an external
or cross compiler toolchain.




-adrian


More information about the freebsd-hackers mailing list