Date: Wed, 10 Apr 2013 09:50:04 -0500
From: Brooks Davis <brooks@FreeBSD.org>
To: Lev Serebryakov <lev@FreeBSD.org>
Cc: deeptech71 <deeptech71@gmail.com>, freebsd-hackers@FreeBSD.org
Subject: Re: building world and kernel without ebuilding ("bootstrap"?) clang?
Message-ID: <20130410145004.GA66560@lor.one-eyed-alien.net>
In-Reply-To: <1952710103.20130410180935@serebryakov.spb.ru>
References: <5164815A.6040908@gmail.com> <1952710103.20130410180935@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Wed, Apr 10, 2013 at 06:09:35PM +0400, Lev Serebryakov wrote: > Hello, deeptech71. > You wrote 10 ???????????? 2013 ??., 1:00:10: > > d> Lev Serebryakov wrote: > >> Is "system" version (system is snapshot from Mar 30) is "external" and "modern"? > > d> Lev Serebryakov wrote: > >>It is very sad, that external compiler cannot be used with "fresh" > >> sources (when headers are different). We need some solution for this, > >> for sure! When compilers are identical (same clang revision), but > >> sources has updated headers. It does proper trick with libraries, but > >> not with headers! > > d> Compiler headers are not the main problem. The base system is > d> generally compilable with any compiler, modulo the main problem. > > d> Source files in /usr/src should include (ie., #include <...>) > d> headers from /usr/src/include, but in case of an external compiler, > d> they don't, they actually include the headers from /usr/include > d> (don't think about stdio.h, but rather about things like > d> net80211/ieee80211_mesh.h)! The main problem occurs when library > d> headers change (eg., an import of a newer version of > d> /usr/src/contrib/somelib). It happens that the source files need a > d> new definition (eg., #define IEEE80211_MESHRT_FLAGS_GATE 0x08), but > d> such is not found in /usr/include, only in /usr/src/include. > I speak exactly about this situation. > > d> However, during ``make installworld'', headers get copied from > d> /usr/src/include to /usr/include, so after that, /usr/include is > d> equivalently usable. After that, compilation won't fail just due to > d> this issue... until /usr/src is significantly updated again. > Yep. And it happens rather often for -CURRENT. > > d> When Clang or GCC is built as part of "make buildworld", it is > d> also built specially once: a bootstrapped compiler uses > d> /usr/obj/tmp/usr/include (a copy of /usr/src/include) instead of /usr/include. > I wonder, is it possible to add some options to base compiler to > make it use /usr/obj/tmp/usr/include when it build world... The key is to pass the --sysroot option to the compiler. I've got a not quite finished (mostly due to a complete lack of documentation) set of patches to Makefile.inc1 to do this: http://people.freebsd.org/~brooks/patches/xcc3.diff If you set XCC=/path/to/clang XCXX=/path/to/clang++ XCPP=clang-cpp then when building world and kernel you will use those compilers and not build a cross compiler. In that mode you will still build and use a cross binutils > Reduction of build time from 1:27 to just 0:27 is very impressive > and useful. > > Also, it looks like clang is cross-compiler always, i.e base clang > could build binaries for any supported platform, not only for > platform which is the same as host one... It expands possibility of > using base compiler to fast build experimental builds for embedded > devices even more. The above patches support cross build using clang. -- Brooks [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRZXwbXY6L6fI4GtQRAp5hAKDSq/f1gMSNCsfcr9VONAF0mY4T9QCfWHYj gLu3uPo8ssbvc7rnJtzouvA= =nfJG -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130410145004.GA66560>