Date: Wed, 27 Feb 2013 15:44:45 -0600 From: Brooks Davis <brooks@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] external compiler support Message-ID: <20130227214445.GA19594@lor.one-eyed-alien.net> In-Reply-To: <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 02:01:42PM -0700, Warner Losh wrote: >=20 > On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote: >=20 > > On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote: > >> Ooops, forgot to add one item.. > >>=20 > >>=20 > >> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote: > >>=20 > >>>=20 > >>> On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: > >>>=20 > >>>> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you > >>>> can find an initial patch with proposed commit for external compiler > >>>> support. It relies on the existing cross binutils as I'm finding th= at > >>>> the two are fairly separable. With this patch I've been able to bui= ld > >>>> from amd64 to arm, amd64, and i386 using clang from the lang/clang-d= evel > >>>> port. I've also compiled the tree with a customized clang being > >>>> developed at the University of Cambridge. > >>>=20 > >>> Cool! > >>>=20 > >>>> The patch is untested with gcc. > >>>=20 > >>> I'd like to see it tested with gcc :) > >>>=20 > >>>> Does this seem like a reasonable approach? I do plan to look at ext= ernal > >>>> binutils support, but it's not on the critical path for our current = work > >>>> so I've opted to avoid it for now. > >>>=20 > >>> The patches I posted a few months ago had that as well... > >>>=20 > >>>> As a bonus for those who don't need an external compiler, but do run > >>>> make buildworld frequently, the XCC, XCXX, and XCPP variables can be= set > >>>> to the location of the installed base system compiler to avoid build= ing > >>>> the compiler twice during buildworld. > >>>=20 > >>> I think this will work, but it is kludgy. I had created a __X=3D<pre= fix-path> which was prepended to ${CC}, et al, in sys.mk. It was only defin= ed when you set CROSS_COMPILER_PATH (or EXTERNAL_COMPILER_PATH, I forget) d= uring the cross building stage. It also had the advantage of making externa= l cross binutils available. Your patch could fairly easily use this interfa= ce instead of having to set 3 different variables, which will morph to 10 w= hen you add binutil support. > >>=20 > >=20 > > I think something like this will have to be done for binutils given the > > way -B works, but I don't think it's workable in the general compiler > > case because I want to be able to use gcc46 or a future clang33 or > > similar as CC without changing the system compiler. Ideally I'd > > also like to support clang's method of finding appropriate binutils > > by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then > > /binutils/path/tool. >=20 > I didn't know that clang did this, but that's certainly doable. The key is that for it to work we need to set each tool's name individually. > > As a strawman, let's say we add a CROSS_COMPILER_PATH and a > > CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if they > > are unset. The latter will control -B and set the various binutils > > variables (XNM, XLD, etc). >=20 > I'm not sure I like splitting things like that. It is unnatural. That's the traditional view with lots of historic merit. At least in the short term it's not a useful view for me. I want to be able to use our existing infrastructure to build a cross binutils and then use it with an external compiler. In a clang world, we currently have one compiler and many binutils unless we gratuitously build many compilers as the FreeBSD build system currently does. Some day we will likely have an all-llvm toolchain available and then we will have one toolchain for all supported architectures. I suppose could hack what I want to do into the traditional single toolchain world view by build a mips64 xdev toolchain and then building a linkfarm and/or set of wrapper scripts to it and the clang I want to include, but that seems problematic from a reproducability perspective (not to mention performance if I need wrappers to set -B). Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be a useful compromise in this regard. -- Brooks --opJtzjQTFsWo+cga Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLn5MXY6L6fI4GtQRAuMtAJ47zXiVZtsVnO1YsKGLjzCwVsnQuQCgi7eG 8XEnYLhtJ3UYYyE5yfW5wfI= =onj4 -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130227214445.GA19594>