From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 19:08:07 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18020772 for ; Wed, 27 Feb 2013 19:08:07 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8F3887 for ; Wed, 27 Feb 2013 19:08:04 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RJ8496019055; Wed, 27 Feb 2013 13:08:04 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RJ84F1019054; Wed, 27 Feb 2013 13:08:04 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 13:08:04 -0600 From: Brooks Davis To: Warner Losh Subject: Re: [RFC] external compiler support Message-ID: <20130227190804.GB17489@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:08:07 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 that > >> the two are fairly separable. With this patch I've been able to build > >> from amd64 to arm, amd64, and i386 using clang from the lang/clang-dev= el > >> 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 exter= nal > >> binutils support, but it's not on the critical path for our current wo= rk > >> 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 s= et > >> to the location of the installed base system compiler to avoid building > >> the compiler twice during buildworld. > >=20 > > I think this will work, but it is kludgy. I had created a __X=3D which was prepended to ${CC}, et al, in sys.mk. It was only defined= when you set CROSS_COMPILER_PATH (or EXTERNAL_COMPILER_PATH, I forget) dur= ing the cross building stage. It also had the advantage of making external = cross binutils available. Your patch could fairly easily use this interface= instead of having to set 3 different variables, which will morph to 10 whe= n you add binutil support. >=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. 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). The sys.mk solution seems clean at first glance, but I don't think it's sufficently general. It's also insufficient because you need --sysroot unless you want to build a sysroot somewhere and hardcode paths to it into your toolchain. Worse, if you want rescue to work, --sysroot must be part of CC etc because crunchgen doesn't make it easy to manipulate CFLAGS. > I've also started looking into using clang --mumble to doing cross builds= too, so I don't have to have 4 compilers configured and laying around for = the different platforms I play with. That isn't reflected in the port. >=20 I'm not sure what you mean by "That isn't reflected in the port". -- Brooks --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLlmTXY6L6fI4GtQRAofbAKCopj7smMltMQoPyGfIgzdm2pOi5ACeNTl0 Pc/QCuHxdfM+ASNWYl1hTFA= =f5rX -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx--