Date: Wed, 12 Aug 2015 00:33:30 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: John Baldwin <jhb@freebsd.org> Cc: Baptiste Daroussin <bapt@freebsd.org>, Adrian Chadd <adrian.chadd@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Bill Sorenson <instructionset@gmail.com> Subject: Re: Sparc64 support Message-ID: <20150811223330.GA51727@alchemy.franken.de> In-Reply-To: <3293168.mJnTOSukKj@ralph.baldwin.cx> References: <CACcTwYmS1c5uoO-WiJQDwgqYAevX7WZ7ZrP297hnOu7cNET3CA@mail.gmail.com> <CAJ-VmomyKJaVhBR5=Dny%2BUpKoV6wmJJGNR6UKgjWq0UBRz=sMQ@mail.gmail.com> <20150808015610.GL43782@ivaldir.etoilebsd.net> <3293168.mJnTOSukKj@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 11, 2015 at 11:02:03AM -0700, John Baldwin wrote: > On Saturday, August 08, 2015 03:56:10 AM Baptiste Daroussin wrote: > > On Fri, Aug 07, 2015 at 04:54:46PM -0700, Adrian Chadd wrote: > > > Hi, > > > > > > I've tested it with mips/mips64. It works out mostly okay. There are > > > still rough edges, because in the mips world we have different > > > defaults in our base system gcc to what the current toolchain expects. > > > But at least for mips/mips64 it spits out a kernel and binaries that > > > work. > > > > > > What I did to make the MIPS bits call the external toolchain: > > > > > > make <existing options> NO_WERROR=1 CROSS_TOOLCHAIN=mips-gcc buildworld > > > > > > .. so in theory the sparc64 stuff may just be: > > > > > > pkg install sparc64-gcc sparc64-xtoolchain-gcc > > > make <existing stuff> NO_WERROR=1 CROSS_TOOLCHAIN=sparc64-gcc buildworld > > > > > When I added the cross toolchain it was first tested on sparc64 and people > > reported that it built and run fine with it. > > > > This was with gcc 4.9, I haven't tested with 5.2 > > Should we perhaps looking at switching the default toolchain for sparc64 to > external similar to how we require external binutils for aarch64? > If you: o created and are willing to maintain long-term support system toolchain ports (the regular upstream binutils and GCC releases are way too much of a moving target to justify their existence alone, i. e. I cannot remember a single in-tree toolchain update where newly introduced bugs in binutils and/or GCC did not cause regressions like C++ exceptions no longer working on any of !x86 at that time, kernel modules no longer working on sparc64, etc.), o ensured release building works with the external toolchain, and o fixed the chicken and egg problem of obtaining a system toolchain on the cross-built target bapt@ pointed out, then: yes. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150811223330.GA51727>