Date: Sat, 2 Apr 2011 12:47:33 -0600 From: Warner Losh <imp@bsdimp.com> To: Robert Watson <rwatson@freebsd.org> Cc: mdf@freebsd.org, Dimitry Andric <dim@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Include file search path Message-ID: <742085CD-7F6F-4879-9FFD-517EC3203D52@bsdimp.com> In-Reply-To: <alpine.BSF.2.00.1104021925110.67810@fledge.watson.org> References: <AANLkTi=BiUVnzsGg83wwWPHjnTDR=XukhJ3UK6Bd5hvF@mail.gmail.com> <4D934AF4.9080503@FreeBSD.org> <BB9CDEF6-5B59-47F3-8873-78D71E39BF3E@bsdimp.com> <alpine.BSF.2.00.1104021925110.67810@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?742085CD-7F6F-4879-9FFD-517EC3203D52>