<div dir="ltr"><div>Hi Chris,</div><div><br></div><div>Thanks for taking the time to raise this issue.<br>I know I have been a bit pushy about getting it solved.</div><div><br></div><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">I think either (1) should be implemented. Or (4) - make the libraries<br></span><span style="font-size:12.8px">just to be "shimmed" on fly - proving empty libs for the configure<br></span><span style="font-size:12.8px">time just to pacify cmake.</span></blockquote><div>Unfortunately option 4 here wont work for some targets.<br>The specific one I am dealing with is mingw-w64.<br>The mingw-w64-crt depends on some functions internally in libgcc/compiler-rt to even build a return 0 from main empty executable.<br>So this would still fail at link time.<br>This could have been a solution if we were dealing with linux targets only.</div><div><br></div><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">In my case, I had to use the CMAKE_{C,CXX}_COMPILER_FORCED variables and<br></span><span style="font-size:12.8px">guestimate the appropriate C/C++ flags in order to avoid CMake getting in the<br></span><span style="font-size:12.8px">way with the various checks. My scripts build clang & lld, then install the<br></span><span style="font-size:12.8px">linux's kernel & Musl's C library headers and finally build compiler-rt's<br></span><span style="font-size:12.8px">builtins library (by setting COMPILER_RT_BUILD_SANITIZERS=</span><span style="font-size:12.8px">Off). The next steps<br></span><span style="font-size:12.8px">build Musl, libunwind, libcxx and libcxxabi. This way I'm able to "use" CMake<br></span><span style="font-size:12.8px">for every LLVM project.</span></blockquote><div> </div><div>This is exactly how I am working around this atm for the mingw-w64 target.<br>Do you have your scripts somewhere I would like to compare?<br><br><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">IMHO, from the options that you've mentioned, (3) is the cleanest one.<br></span><span style="font-size:12.8px">Conceptually, as you mentioned the builtins library does not belong with the<br></span><span style="font-size:12.8px">sanitizers and it would make sense splitting them in separate repositories.<br></span><span style="font-size:12.8px">Would it be too difficult to create an initial split given that we already<br></span><span style="font-size:12.8px">provide/support the COMPILER_RT_BUILD_BUILTINS and COMPILER_RT_BUILD_SANITIZERS<br></span><span style="font-size:12.8px">options?</span></blockquote>The issue seems to be that even if we set <span style="font-size:12.8px">COMPILER_RT_BUILD_SANITIZERS to off it still does all the checks.</span><br><span style="font-size:12.8px">Maybe it would be possible from within the cmakelists of compiler-rt to seperate them out more to avoid this when we are just building the builtins?</span><br><span style="font-size:12.8px">This seems like a decent first step forward regardless if it is agreed to separate out into 2 different projects.<br></span><br><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">I'm not sure if this jibes with your statement, but IMHO, the<br></span><span style="font-size:12.8px">refactored built-ins should move into the LLVM repo.  In this spirit,<br></span><span style="font-size:12.8px">I believe gcc includes libgcc in-tree.  Being both a small library and<br></span><span style="font-size:12.8px">intimately tied to LLVM, the complexity of a new separate built-ins<br></span><span style="font-size:12.8px">repo is a little dubious.  The sanitizers are a separate can of worms.</span></blockquote><div><br></div><div>This was something I also was thinking about.<br>There are complexities here though because unlike gcc, llvm is multi target based.</div><br>- Martell<br><span style="font-size:12.8px"> </span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 9:01 PM, Steve King via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris - Many thanks for airing all this.   I'm now hopeful for an<br>
end to my own hacks and false starts trying to fix these same<br>
problems.  My response is coming from the perspective of an<br>
out-of-tree target without binutils or libgcc support.<br>
<br>
On Mon, Nov 2, 2015 at 9:10 AM, Chris Bieneman via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> (3) Split the built-ins and the runtime libraries<br>
<br>
+1.  Eliminating unnecessary entanglement is good engineering and<br>
helps especially in the overwhelming early days of new target<br>
development.<br>
<br>
> I believe that the cleanest solution to this problem is going to be to separate the built-ins and the sanitizers.<br>
<br>
+1, again for sensible modularity and being merciful on new targets.<br>
<br>
> Logistically this solution could take many forms. We could break compiler-rt out into two repositories, which would be a huge undertaking, or we could leave it as a single repository and have the built-ins be able to build as a sub-project. I think we can make it work such that compiler-rt can be built either from the top-level directory to build it all, or from the built-ins sub directory to support bootstrapping cross-compilers.<br>
<br>
I'm not sure if this jibes with your statement, but IMHO, the<br>
refactored built-ins should move into the LLVM repo.  In this spirit,<br>
I believe gcc includes libgcc in-tree.  Being both a small library and<br>
intimately tied to LLVM, the complexity of a new separate built-ins<br>
repo is a little dubious.  The sanitizers are a separate can of worms.<br>
<br>
Thanks,<br>
-steve<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>