Sparc64 support

[Jordan Hubbard]

> On Aug 11, 2015, at 12:02 AM, Dieter BSD <dieterbsd at gmail.com> wrote:
> 
> I keep seeing the same issues over and over.  Cross builds don't
> work.  Some people hate gcc for whatever reason and insist on
> ripping it out in hopes that someone will wave their magic wand and
> make some other compiler take over.

That is an overly simplistic summary of the discussion so far.  If cross-builds don’t work, they’re not going to work with any compiler toolchain.  Everyone needs to be very clear about this:  This isn’t even *about* gcc and whether or not anyone “hates” it.  We’ve already said multiple times in this thread that an external toolchain is absolutely desirable, and that toolchain will almost certainly be gcc until/unless someone gets a real hard-on to start trying Intel System Studio or something, the problem is FreeBSD’s “area of interface” with the compiler toolchain and the degree to which it’s not yet capable of dealing with toolchain selection in a clean and understandable (or hell, even fully functional) way.

The fact is that, in the year 2015, not being able to build with a selection of compiler toolchains is just lame.  What’s even lamer is that it doesn’t even appear to be the case that the problem is purely related to “which” toolchain so much as a lack of clarity on HOW to actually use the various toolchains necessary for various architectures!   As multiple people have asked in this thread, and still with no clear answer:  “Can someone kindly tell us just HOW specifically to compile for MIPS / sparc64 / PowerPC / etc?   What flags do we use?  What versions of gcc do we even use?  Can we use the official version(s) or do we have to apply patches first?”

That’s just building.  That doesn’t even cover the release media building issues I’ve also raised in this thread, where it’s not even necessarily clear how to build installation media for all the various machine targets FreeBSD now supports, all part of the “clean up the build system” agenda I’ve been trying to at least raise awareness of here.

You can’t possibly believe that this situation can be hand-waved away as a “gcc haters gonna hate!” discussion with those sorts of questions open.  It doesn’t sound like anyone has even really TRIED to take a systematic approach to cross building.  Different people have focused on their individual architectures of interest and that’s been about it.   It also doesn’t sound like any compiler, currently in base or otherwise, can fulfill the full mission goals for all Tier 1 and Tier 2 targets, so *obviously* this is going to require that the choice of toolchain be configurable.  That’s not “rip gcc out”, that’s “make gcc actually WORK” for cross-building since there is yet to be any one-size-fits-all compiler toolchain available (it would be really nice and simple if there were, but there isn’t and we can’t have a pony, either).  

> NASA_BSD got the cross-arch cross-OS building stuff working
> *years* ago.  Is there some valid reason that FreeBSD can't
> do it the same way?  NIH is not a valid reason.

Where are those changes?  Which version of FreeBSD were they forked from?  By all means, elaborate!   I’m sure “NIH” is not the objection, but probably more the case that few people have even heard of “NASA BSD” (I’ve certainly never heard of it and Google is strangely silent on the topic).   Even the most brilliant but completely obscure solution remains obscure, and I don’t know what NASA did with their amazing BSD fork but “get it upstreamed” was evidently not on their list of desires or we might not even be having this discussion.

> There seems to be an assumption that all arches have to use the same toolchain.

I’m not sure we have been reading the same thread.  The last 5 message I read specifically noted that all arches COULDN’T use the same toolchain.  How do you get “have to” from “can’t?”

> I see a lot of hatred towards the less popular, "weird" arches.
> Having a variety of arches has a *lot* of value.

I’m sorry, but on top of the points above where I think you’re fairly far off-base, you could not be more wrong here either.  Even NetBSD, which has long had the motto of “of course it runs NetBSD!” (as if the answer was so obvious as to be unworth the question), has been retiring architectures left and right because there is no such thing as “free” in software.  Everything has a cost in time, in complexity, in maintenance headaches, etc.  You absolutely MUST weigh the relative value of each and every platform (or HW device) you support and be willing to ruthlessly cull the old and the weak or before long, your software will be a collection of burdensome conditionals and weird constructs that no one even understands the purpose of anymore, but “they were necessary for something, at some point” so no one dares remove them, either.

Just ask the OpenSSL project how heavy the burden of history can be (and look at how many lines of code LibreSSL has ripped out, often with great glee) and then ask yourself again if your definition of “value” is truly aligned with the converse reality we objectively know to be true

- Jordan