svn commit: r200797 - head/lib/libc/stdtime
Doug Barton
dougb at FreeBSD.org
Tue Dec 29 05:00:01 UTC 2009
M. Warner Losh wrote:
> In message: <4B3129CD.20908 at FreeBSD.org>
> Doug Barton <dougb at FreeBSD.org> 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...
The details of what compiler we use in the base aren't really
interesting to me for the purpose of this discussion. I hope that we
can find a BSD licensed alternative that's suitable for the base, but
I think we are already getting left behind in terms of "things that
require more recent compilers" and it's only going to get worse.
> : 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?
You're disregarding this as a possible solution because the concept
doesn't fit your idea of what's possible or desirable. With all due
respect I think closing your mind to the possibility is premature.
> Does the build-world stop in the middle and rebuild stuff?
Huh? Are you asking whether a world build with a compiler from ports
should rebuild the port(s)? If so, I think the answer is pretty
obviously no.
> Right now we have finely matched libraries and
> compilers, how does one address that problem with the compiler out in
> the ports?
One could argue that the current situation is actually not desirable,
and making it more "plug and play" is a good goal regardless of what
compiler we use.
> 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.
Funny, I feel the same way about the current system. :)
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
More information about the svn-src-all
mailing list