Include file search path

[Warner Losh]

On Apr 2, 2011, at 12:29 PM, Robert Watson wrote:

> 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.

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