Date: Sat, 2 Apr 2011 19:29:48 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: mdf@freebsd.org, Dimitry Andric <dim@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Include file search path Message-ID: <alpine.BSF.2.00.1104021925110.67810@fledge.watson.org> In-Reply-To: <BB9CDEF6-5B59-47F3-8873-78D71E39BF3E@bsdimp.com> References: <AANLkTi=BiUVnzsGg83wwWPHjnTDR=XukhJ3UK6Bd5hvF@mail.gmail.com> <4D934AF4.9080503@FreeBSD.org> <BB9CDEF6-5B59-47F3-8873-78D71E39BF3E@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Mar 2011, Warner Losh wrote:
> 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.
>
> 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.
>
> 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).
Count me as another eager consumer awaiting a nice answer to the general
cross-compile problem. I'm really looking for three things:
(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.
(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?
(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?
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.
Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1104021925110.67810>