<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 3, 2015, at 6:33 AM, Martell Malone <<a href="mailto:martellmalone@gmail.com" class="">martellmalone@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px" class="">Sure. I’m not sure if everyone will agree with me, but my general assertion is that if you’re doing a full bootstrap of a cross compiler, we’re not going to fully support that from a single CMake build tree. We didn’t support that in autoconf, so I don’t think CMake should be different in that regard. I envision bootstrapping a full cross-platform to be something like:</span><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">(1) build in-tree clang<br class=""></span><span style="font-size:12.8px" class="">(2) build out-of-tree builtin library<br class=""></span><span style="font-size:12.8px" class="">(3) build out-of-tree runtime libraries</span></blockquote><div class=""><br class=""></div><div class="">This seems reasonable to me.<br class="">The default int-tree stuff should be for the host.<br class="">I don't think many will have issue with doing out of tree builds or the builtins or the runtime if they are cross compiling.<br class=""></div></div></div></blockquote><div><br class=""></div><div>Cool. This then makes your other point about requiring LLVM tools less of an issue because the out-of-tree builds can use whatever tools you choose. We just need to make the builtins work so that you don’t need them already built.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px" class="">Today there isn’t really a simple answer. For Linux I think the bootstrap only builds for the host architecture by default. For Darwin, it builds all supported Darwin architectures, which can be complicated to determine.</span></blockquote><div class="">Not quite sure why IOS is built by default on darwin it should probably be OSX only and out of tree for IOS like you said above.<br class="">Doubt many will agree with changing this now though.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>I’m the one who landed a lot of that code, and I want to rip it all out. We just need to make it work the right way before we can rip it out.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div></div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:12.8px">> This might be mission creep, but it's a drag that the unspoken first<br class=""></span><span class="im" style="font-size:12.8px">> step in developing an LLVM based toolchain is "port binutils". I<br class=""></span><span class="im" style="font-size:12.8px">> haven't kept watch on LLD progress, but perhaps it's far enough along<br class=""></span><span class="im" style="font-size:12.8px">> that bootstrap process can depend on it.</span><span style="font-size:12.8px" class=""><br class=""></span><span style="font-size:12.8px" class="">On Darwin ar and lld are the biggest pieces that aren’t fully featured yet. </span></blockquote><span style="font-size:12.8px" class=""><br class="">Yes Darwin seems to be the biggest blocker here with the least amount of work gone into it.<br class="">The COFF and ELF linkers have been replaced with section based ones as that makes more sense.<br class="">I don't know enough about MachO to say if would be better with switching or staying with an atom based design.<br class=""></span></div></div></div></blockquote><div><br class=""></div><div>Not to re-hash an old argument, but Apple has no interest in a section-based MachO linker. We already have a great one of those that doesn’t have the licensing issues that come with binutils. What we do want is a better optimizing linker, which is what is leading us to support the atom-based design.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><span style="font-size:12.8px" class="">It would be great if maybe an apple engineer more in the know would nominate them selves </span><span style="font-size:12.8px" class="">and bring it up to par with the rest and then maybe</span><span style="font-size:12.8px" class=""> become an OWNER.</span></div></div></div></blockquote><div><br class=""></div><div>Lang has been putting a lot of work into that, and he did nominate himself as code owner, it is even reflected in the CODE_OWNERS list. The only parts of LLVM that I think don’t build correctly with LLD on MachO are some of the runtime libraries, but I expect that will get fleshed out soon enough too.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><span style="font-size:12.8px" class=""><br class=""></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px" class="">On other platforms I think there are still places that lld isn’t fully fleshed.</span></blockquote><div class="">Yes there are some parts still missing and that are wip but the new COFF and ELF section based linkers should bootstrap just fine.<br class=""><br class="">Just as a point for building the builtins shouldn't we just need llvm-ar ?<br class="">While not being feasible for the Darwin target as you said above it should be perfectly fine for windows and linux.<br class="">I don't think we should even need the linker to bootstrap the builtins or am I incorrect in saying this ?<br class="">If so I think it think it would be reasonable to have that as the mission creep.</div></div></div></div></blockquote><div><br class=""></div><div>I think that since bootstrapping will be an out-of-tree build there is no reason to require a fully LLVM toolchain as it doesn’t get us anything. Once we make the builtins work just requiring a compiler, ar, and ranlib there is nothing stopping anyone from bootstrapping with a fully LLVM toolchain on Linux.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Nov 3, 2015 at 12:03 AM, Chris Bieneman via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> On Nov 2, 2015, at 2:44 PM, Steve King <<a href="mailto:steve@metrokings.com" class="">steve@metrokings.com</a>> wrote:<br class="">
><br class="">
> On Mon, Nov 2, 2015 at 1:02 PM, Chris Bieneman <<a href="mailto:beanz@apple.com" class="">beanz@apple.com</a>> wrote:<br class="">
>> Sadly, I believe there are licensing reasons why the builtins can’t be in the LLVM repo.<br class="">
><br class="">
> Repos and licenses are orthogonal, but I get the concern.<br class="">
><br class="">
> Switching gears to other questions:<br class="">
> Should the bootstrap build automatically produce a built-ins library<br class="">
> for each target in "llvm-config --targets-built" or is the developer<br class="">
> expected to provide an explicit list? Hopefully the former.<br class="">
<br class="">
</span>Today there isn’t really a simple answer. For Linux I think the bootstrap only builds for the host architecture by default. For Darwin, it builds all supported Darwin architectures, which can be complicated to determine.<br class="">
<span class=""><br class="">
><br class="">
> Is it reasonable that bootstrap build not depend on GNU binutils?<br class="">
<br class="">
</span>Not necessarily. To my understanding LLVM doesn’t fully replace bin utils on any platform yet, and I think we’re a long way from saying the LLVM toolchain is the default builtin toolchain.<br class="">
<span class=""><br class="">
> This might be mission creep, but it's a drag that the unspoken first<br class="">
> step in developing an LLVM based toolchain is "port binutils". I<br class="">
> haven't kept watch on LLD progress, but perhaps it's far enough along<br class="">
> that bootstrap process can depend on it.<br class="">
<br class="">
</span>On Darwin ar and lld are the biggest pieces that aren’t fully featured yet. On other platforms I think there are still places that lld isn’t fully fleshed.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
-Chris<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
><br class="">
> Regards,<br class="">
> -steve<br class="">
<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>