From owner-svn-src-head@FreeBSD.ORG Sat Dec 26 08:28:40 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D34461065670; Sat, 26 Dec 2009 08:28:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 74C448FC1A; Sat, 26 Dec 2009 08:28:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id nBQ8Lobv007676; Sat, 26 Dec 2009 01:21:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 26 Dec 2009 01:22:31 -0700 (MST) Message-Id: <20091226.012231.475505532728794904.imp@bsdimp.com> To: dougb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4B3129CD.20908@FreeBSD.org> References: <20091221220004.GA42400@alchemy.franken.de> <20091221.211648.632868945383134253.imp@bsdimp.com> <4B3129CD.20908@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, jhb@FreeBSD.org, marius@alchemy.franken.de Subject: Re: svn commit: r200797 - head/lib/libc/stdtime X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 26 Dec 2009 08:28:40 -0000 In message: <4B3129CD.20908@FreeBSD.org> Doug Barton writes: : M. Warner Losh wrote: : > We really need newer binutils in the tree. : > : > And we need a way to compiler gplv3 binutils into the system for folks : > that can do that without consequences... But many modern processors : > need to have the gplv3 version of binutils and that will be a : > continuing problem. One advantage of FreeBSD is its integration, : > rather than having to play version whack-a-mole like you do with : > embedded Linux. : : When "we" last had the gplv3 discussion there were two lines of : thought that were proposed. One is "import llvm/clang" and the other : was "improve the infrastructure to support toolchains from ports." I : know that the llvm/clang project is moving forward, and I think that's : a great long-term direction. Assuming that it supports the architectures we need well, which at the present time it isn't clear that it will... : In the short term I think we are well served on all fronts to modify : the build architecture to better support compilers from ports. This : would actually help with the llvm/clang testing too, and sidestep the : problems of gplv3 stuff being in the base. TMK there has been no work : on this direction at all, which is disappointing. The problem is that it really isn't a terribly viable solution, so why waste a bunch of time on it? Does the build-world stop in the middle and rebuild stuff? Right now we have finely matched libraries and compilers, how does one address that problem with the compiler out in the ports? You'll need a matched set of binutils as well (well, matched meaning known compatible here), and the build system has a strong bias towards the compiler knowing which ones to use.. These problems can all be surmounted, but it just feels like a big kludge. : I know that there is a huge cultural bias towards shipping "a complete : system," and don't get me wrong, I am fully supportive of that. I am : NOT suggesting that we dike out the existing toolchain. Just that we : make it easier to use toolchains from ports. Agreed. I'll likely be working in this area soon. Last time I tried, it was possible, but very difficult and error-prone to do it by hand... Warner