<div dir="ltr">On Mon, Sep 23, 2013 at 12:20 PM, Tom Roeder <span dir="ltr"><<a href="mailto:tmroeder@google.com" target="_blank">tmroeder@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<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">I think it could be refactored along these lines. I was hoping for<br>

clients of the library not to have to know about the dependency but<br>
simply to get it implicitly by depending on lib/LTO. Is there a way to<br>
do this using llvm-build?<br></blockquote><div><br></div><div>No, but thats a feature. The goal is that the ultimate library clients always get to choose what targets they support, so individual libraries aren't supposed to force any particular target linkage.</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">
<br>
After looking through the code a bit, I see that the only callers of<br>
the InitializeAll* routines are in tools/. So, if this is the existing<br>
design direction, then I'll see about pulling those parts up into<br>
clients of lib/LTO.<br></blockquote><div><br></div><div>Cool, thanks!</div><div><br></div><div> - Daniel</div><div>  </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 class=""><font color="#888888"><br>
Tom<br>
</font></span><div class=""><div class="h5"><br>
On Mon, Sep 23, 2013 at 11:50 AM, Daniel Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<br>
> Hi Tom,<br>
><br>
> Can you explain why lib/LTO needs to depend on all-targets? I'm not sure we<br>
> actually want this behavior, what we generally want is that clients can pick<br>
> the library and then pick the list of targets that get included. In this<br>
> case, I think the right thing that should happen is that both tools/lto and<br>
> llvm-lto depend on all targets and handle the target initialization, whereas<br>
> lib/LTO itself just relies on the targets already having been initialized.<br>
><br>
> Is it possible to factor lib/LTO in that fashion?<br>
><br>
>  - Daniel<br>
><br>
><br>
> On Fri, Sep 20, 2013 at 11:59 PM, Tom Roeder <<a href="mailto:tmroeder@google.com">tmroeder@google.com</a>> wrote:<br>
>><br>
>> I've written a patch now (in consultation with Peter) that does<br>
>> exactly this: tools/llvm-lto is split into a lib/LTO component and a<br>
>> tools/llvm-lto component, and tools/llvm-lto is written to depend only<br>
>> on lib/LTO (and not tools/lto, hence not libLTO.so). This should solve<br>
>> the problems with the freebsd build and additionally be a better<br>
>> factorization of the code.<br>
>><br>
>> However, this design led to an interesting problem: lib/LTO needs to<br>
>> depend on all-targets, and having a library that depends on<br>
>> all-targets wasn't supported by the existing llvm-build scripts (the<br>
>> required_libraries of all-targets came up with empty<br>
>> required_libraries of their own). So, I've modified<br>
>> llvm-build/llvmbuild/main.py to fill out these implicit dependencies,<br>
>> using the information from the add_to_library_groups entries in the<br>
>> LLVMBuild.txt files.<br>
>><br>
>> I've run clean builds with cmake/ninja, cmake/make, and Makefile and<br>
>> run check successfully on each of them (on Linux). And I've built<br>
>> LLVMgold.so against the Makefile version and tested it on a simple<br>
>> test file (the test case from this patch).<br>
>><br>
>> However, my patch as it stands combines svn mv operations with edits<br>
>> on the moved files, so it's far more verbose than necessary and loses<br>
>> some of the history information (by not exactly capturing the move<br>
>> information). Would you like me to formulate this as two patches: a<br>
>> move followed by edits?<br>
>><br>
>> Please let me know what you think.<br>
>><br>
>> Thanks,<br>
>><br>
>> Tom<br>
>><br>
>> On Fri, Sep 20, 2013 at 12:50 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>><br>
>> wrote:<br>
>> > On Fri, Sep 20, 2013 at 12:25:17PM -0700, Tom Roeder wrote:<br>
>> >> Actually, it looks like libLTO.so simply isn't getting built or found<br>
>> >> here<br>
>> >> and that's why the test is failing.<br>
>> ><br>
>> > Hm?  The compile log:<br>
>> ><br>
>> > <a href="http://lab.llvm.org:8011/builders/clang-X86_64-freebsd/builds/10381/steps/compile/logs/stdio" target="_blank">http://lab.llvm.org:8011/builders/clang-X86_64-freebsd/builds/10381/steps/compile/logs/stdio</a><br>

>> > seems to indicate that libLTO is being built.<br>
>> ><br>
>> > I suspect that the problem is that the rpath isn't being embedded<br>
>> > in the llvm-lto binary on FreeBSD in the correct way, though I can't<br>
>> > tell for sure, since I don't have access to a FreeBSD machine.<br>
>> ><br>
>> > I'm beginning to think that the right way to solve this problem is<br>
>> > to move LTOCodeGenerator.cpp and LTOModule.cpp in tools/lto into<br>
>> > a new component 'lto' in lib/LTO and have tools/lto (which would<br>
>> > then contain only the C interface) and tools/llvm-lto (and maybe<br>
>> > tools/gold in the future) depend on the lto component.  That way,<br>
>> > the LTO support library is no different to any other component of<br>
>> > LLVM and is less likely to cause problems across platforms.<br>
>> ><br>
>> > Thanks,<br>
>> > --<br>
>> > Peter<br>
>><br>
>> _______________________________________________<br>
>> llvm-commits mailing list<br>
>> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>