svn commit: r249484 - head/lib

[Dimitry Andric]

On Apr 17, 2013, at 17:58, Tim Kientzle <kientzle at freebsd.org> wrote:
> On Apr 17, 2013, at 5:05 AM, Tijl Coosemans wrote:
...
>> So you compile with -ffreestanding -nostdinc?
>> And then add the include path returned by -print-file-name=include?
> 
> That's what the U-Boot sources do, yes.

Why would U-Boot want to build for a freestanding environment, then
include standard headers?  Isn't that a bit backwards? :-)


>>> The -print-file-name=include option works on Linux, works
>>> on MacOS, and --- with this one symlink --- can work on
>>> FreeBSD as well.  I've been using it to cross-build U-Boot
>>> using the FreeBSD xdev toolchain with both GCC and Clang.
>> 
>> "clang -E -v - </dev/null" shows it passes "-resource-dir
>> /usr/bin/../lib/clang/3.3" to cc1 stage which then complains about
>> nonexistent directory "/usr/bin/../lib/clang/3.3/include".
>> 
>> So how about moving /usr/include/clang/3.3 to
>> /usr/lib/clang/3.3/include? That seems to be the location clang
>> expects and what lang/clang port uses (in /usr/local).
> 
> I would certainly like to see that.  I presumed that there
> was some reason this wasn't done in the initial import.

Probably because headers belong under /usr/include, not in a library
directory?  I do not really agree with upstream's decision to place
their internal headers in that location.  Third-party software depending
on their exact location is just a little braindead IMHO.

In any case, the layout has been like this since the initial clangbsd
import, and I never saw any reason to change it.  Maybe Ed can tell a
bit more, since he seems to have done the initial infrastructure setup.


>> The path from -resource-dir is also searched by -print-file-name.
>> 
>> All headers from contrib/llvm/tools/clang/lib/Headers would have
>> to be installed there to have a complete freestanding environment,
>> but some of those headers would have to be patched to use the base
>> system header in the hosted case like the stdint.h header does:
>> 
>> #if __STDC_HOSTED__ && \
>>   defined(__has_include_next) && __has_include_next(<stdint.h>)
>> # include_next <stdint.h>
>> #else
>> ...
>> #endif

Indeed, some of clang's internal headers currently conflict with our
own, due to several declarations and definitions, and therefore we do
not install them at this time.  Again, this could be changed, but not
without good reason.  One specific third-party project is not enough, I
think.  (Especially since our kernel is also freestanding, and does not
depend on these internals.)