From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:25:45 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF8ADC23 for ; Wed, 27 Feb 2013 21:25:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f175.google.com (mail-gh0-f175.google.com [209.85.160.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7CD0ED6 for ; Wed, 27 Feb 2013 21:25:45 +0000 (UTC) Received: by mail-gh0-f175.google.com with SMTP id g18so162664ghb.34 for ; Wed, 27 Feb 2013 13:25:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=+U0p16u3A3WLGmrr4GsQWL+0PFqAwMVnqhAMb5qnVOM=; b=bVrYkka5K6zTFfrj1MynWKorf1GyRb23yQhzm6wfmHxAgFBwu1n3Evircya4GnWxGS u0AtUnMX2/bWsHFwKjygBaHO5fPy+fU3ISwXZme48mDynNC/U6Va78ep0hHv5OZtWVp/ XupRGnslozMSdERBZ1e7mOb+9WN9O3A7t4J+4sHHosd8bFPeVrJuSXR0AT38PvbkcUag 5I9qV7nEiuybuCT4IiBC5BtGKngRbgkl0jYbj7tlONNkWCcLa4E/AuXctFNJhEZbOokt Pe/WoTAbNSABTHF326iNqylyjxyi+brhkjqPRndSnXm4Ogvrf89pkQhujQ4rxZlOqyxd GIaw== X-Received: by 10.236.114.232 with SMTP id c68mr2658640yhh.194.1361998907198; Wed, 27 Feb 2013 13:01:47 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id x16sm9613389yhj.6.2013.02.27.13.01.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 13:01:45 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130227190804.GB17489@lor.one-eyed-alien.net> Date: Wed, 27 Feb 2013 14:01:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Brooks Davis X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlGXAkvigM+cttHshtpP+NDdz4LOLGTbIO1eV7a+CUsxe3fnksLdl/mymtxWkwO7f8JNW0z 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 21:25:45 -0000 On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote: > 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-devel >>>> 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 = external >>>> 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 = 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) during 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 when 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. I didn't know that clang did this, but that's certainly doable. > 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). I'm not sure I like splitting things like that. It is unnatural. > 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. Yes, that's a hole in the current system. My stuff works great for = xdev-build toolchains, but less well for generic toolchains because of = the sysroot issue. that's one part of your patch I especially liked. >> 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 >=20 > I'm not sure what you mean by "That isn't reflected in the port". s/port/patches/ will help. Basically, I did "CC?=3D${__X}cc" when I = should have done "CC?=3D${__X}cc ${__Y}". Warner