Date: Tue, 11 Aug 2015 01:11:58 -0700 From: Jordan Hubbard <jordanhubbard@me.com> To: Dieter BSD <dieterbsd@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Sparc64 support Message-ID: <16D597AE-613F-431F-8F56-30A8908F1913@me.com> In-Reply-To: <CAA3ZYrA0YAGtGHhcv1MJDGAdNBU31_dJ6Y0Fihpce91La=YVZQ@mail.gmail.com> References: <CAA3ZYrA0YAGtGHhcv1MJDGAdNBU31_dJ6Y0Fihpce91La=YVZQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Aug 11, 2015, at 12:02 AM, Dieter BSD <dieterbsd@gmail.com> wrote: >=20 > 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=E2=80=99t work, they=E2=80=99re not going to work with = any compiler toolchain. Everyone needs to be very clear about this: = This isn=E2=80=99t even *about* gcc and whether or not anyone = =E2=80=9Chates=E2=80=9D it. We=E2=80=99ve 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=E2=80=99s =E2=80=9Carea of interface=E2=80=9D with = the compiler toolchain and the degree to which it=E2=80=99s 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=E2=80=99s even = lamer is that it doesn=E2=80=99t even appear to be the case that the = problem is purely related to =E2=80=9Cwhich=E2=80=9D 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: =E2=80=9CCan 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?=E2=80=9D That=E2=80=99s just building. That doesn=E2=80=99t even cover the = release media building issues I=E2=80=99ve also raised in this thread, = where it=E2=80=99s not even necessarily clear how to build installation = media for all the various machine targets FreeBSD now supports, all part = of the =E2=80=9Cclean up the build system=E2=80=9D agenda I=E2=80=99ve = been trying to at least raise awareness of here. You can=E2=80=99t possibly believe that this situation can be hand-waved = away as a =E2=80=9Cgcc haters gonna hate!=E2=80=9D discussion with those = sorts of questions open. It doesn=E2=80=99t 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=E2=80=99s been about it. It also doesn=E2=80=99t 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=E2=80=99s = not =E2=80=9Crip gcc out=E2=80=9D, that=E2=80=99s =E2=80=9Cmake gcc = actually WORK=E2=80=9D 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=E2=80=99t and we can=E2=80=99t = have a pony, either). =20 > 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=E2=80=99m sure =E2=80=9CNIH=E2=80=9D = is not the objection, but probably more the case that few people have = even heard of =E2=80=9CNASA BSD=E2=80=9D (I=E2=80=99ve 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=E2=80=99t know what NASA did with their amazing BSD fork but =E2=80=9C= get it upstreamed=E2=80=9D 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=E2=80=99m not sure we have been reading the same thread. The last 5 = message I read specifically noted that all arches COULDN=E2=80=99T use = the same toolchain. How do you get =E2=80=9Chave to=E2=80=9D from = =E2=80=9Ccan=E2=80=99t?=E2=80=9D > I see a lot of hatred towards the less popular, "weird" arches. > Having a variety of arches has a *lot* of value. I=E2=80=99m sorry, but on top of the points above where I think you=E2=80=99= re fairly far off-base, you could not be more wrong here either. Even = NetBSD, which has long had the motto of =E2=80=9Cof course it runs = NetBSD!=E2=80=9D (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 =E2=80=9Cfree=E2=80=9D 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 =E2=80=9Cthey were necessary for something, at = some point=E2=80=9D 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 =E2=80=9Cvalue=E2=80= =9D is truly aligned with the converse reality we objectively know to be = true - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16D597AE-613F-431F-8F56-30A8908F1913>