From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 18:51:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C4A9106566B; Sat, 2 Apr 2011 18:51:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8148FC18; Sat, 2 Apr 2011 18:51:36 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p32IlXX9055302 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 2 Apr 2011 12:47:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 2 Apr 2011 12:47:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <742085CD-7F6F-4879-9FFD-517EC3203D52@bsdimp.com> References: <4D934AF4.9080503@FreeBSD.org> To: Robert Watson X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 02 Apr 2011 12:47:36 -0600 (MDT) Cc: mdf@freebsd.org, Dimitry Andric , freebsd-hackers Subject: Re: Include file search path X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 18:51:36 -0000 On Apr 2, 2011, at 12:29 PM, Robert Watson wrote: > On Wed, 30 Mar 2011, Warner Losh wrote: >=20 >> On Mar 30, 2011, at 9:23 AM, Dimitry Andric wrote: >>> This is a rather nasty hack, though. If we can make it work, we = should probably try using --sysroot instead, or alternatively, -nostdinc = and adding include dirs by hand. The same for executable and library = search paths, although I am not sure if there is a way to completely = reset those with the current options. >>=20 >> I'm pretty sure that the origins of this hack pre-dates the -sysroot = feature in gcc. It works in -current and has for years, so nobody has = cared enough to even contemplate changing it. >>=20 >> If you can make the sysroot feature work, that would be great, since = that would allow us to skip the compiler building phase if we were = building using external compilers. I have some patches to make that = work, but this very problem is what I'd worked my way up to. It works = well if you are building current on current, but not so well if you are = mixing versions (you can mix architectures if you are using the xdev = feature I put in a while ago, but even that has one or two niggles I = need to iron out). >=20 > Count me as another eager consumer awaiting a nice answer to the = general cross-compile problem. I'm really looking for three things: >=20 > (1) A bit more intelligence from our build framework regarding not = rebuilding > the toolchain quite so many times! I'd like to be able to do a = buildworld > with TARGET_ARCH with significantly improved performance. Perhaps = we can > do this already, in which case a pointer considered welcome. External toolchain will allow us to not build the cross compiler. = another knob will allow us to omit building gcc and binutils for the = target. Between the two of these, we can be good. We already have the cross tool (xdev) targets that can build the FreeBSD = compiler to build on other architectures. This is what I'm using in the = external toolchain work that I've done (it is presently stalled, but = should start up again soon). It turns out that this is necessary for = arbitrary external toolchains, but not sufficient. The xdev targets = build a compiler with a fixed include path which the targets also = install into. Generic external tools will need the -sysroot parameters = passed into the build since they can (and will) be built without it. > (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a = basic > requirement to adopt clang/LLVM, and as far as I'm aware that's not = yet a > resolved issue? 0 work has been done here to my knowledge. The world view for clang and = our in-tree gcc differ which makes it a challenge. > (3) Making it easy to plug in, first, an external gcc easily, and = second, an > external clang/LLVM. One worrying point for me on the last one is = that we > can't yet build the whole kernel with clang/LLVM, at least for = i386/amd64, > so I guess you need both external gcc *and* external clang/LLVM? Yes. The generic external piece is what I'm going towards. > We (Cambridge) are currently bringing up FreeBSD on a new soft-core = 64-bit MIPS platform. We're already using a non-base gcc for our boot = loader work, and plan to move to using clang/LLVM later in the year. = The base system seems a bit short on detail when it comes to the above, = currently. Yes. I've had to add about a dozen changes so far to get close to = building with xdev compilers. A similar number are needed to make it = easy to configure and add systree support, I think. Warner