From owner-svn-src-head@FreeBSD.ORG Wed Apr 17 17:34:01 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5D113725; Wed, 17 Apr 2013 17:34:01 +0000 (UTC) (envelope-from dim@freebsd.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 1CF22871; Wed, 17 Apr 2013 17:34:01 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::dc79:2881:589:7d77] (unknown [IPv6:2001:7b8:3a7:0:dc79:2881:589:7d77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5B0165C45; Wed, 17 Apr 2013 19:33:59 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: svn commit: r249484 - head/lib From: Dimitry Andric In-Reply-To: Date: Wed, 17 Apr 2013 19:33:45 +0200 Content-Transfer-Encoding: 7bit Message-Id: <1FEABB1B-ADDE-412A-9D40-F9FB2822B654@freebsd.org> References: <201304141913.r3EJDqPI095965@svn.freebsd.org> <516D54F5.4010501@FreeBSD.org> <2A0FC59F-E043-4B4E-BABE-E16C6A1FBF5C@freebsd.org> <475555FA-DF6A-42FA-990D-4224ECAEAE52@FreeBSD.org> <516E900B.9090300@FreeBSD.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1503) Cc: Ed Schouten , src-committers@freebsd.org, Juli Mallett , svn-src-all@freebsd.org, Brooks Davis , svn-src-head@freebsd.org, Tijl Coosemans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 17:34:01 -0000 On Apr 17, 2013, at 17:58, Tim Kientzle 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 - > /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() >> # include_next >> #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.)