[llvm] r191042 - Fix LTO handling of module-level assembly (PR14152).

[Tom Roeder]

I've written a patch now (in consultation with Peter) that does
exactly this: tools/llvm-lto is split into a lib/LTO component and a
tools/llvm-lto component, and tools/llvm-lto is written to depend only
on lib/LTO (and not tools/lto, hence not libLTO.so). This should solve
the problems with the freebsd build and additionally be a better
factorization of the code.

However, this design led to an interesting problem: lib/LTO needs to
depend on all-targets, and having a library that depends on
all-targets wasn't supported by the existing llvm-build scripts (the
required_libraries of all-targets came up with empty
required_libraries of their own). So, I've modified
llvm-build/llvmbuild/main.py to fill out these implicit dependencies,
using the information from the add_to_library_groups entries in the
LLVMBuild.txt files.

I've run clean builds with cmake/ninja, cmake/make, and Makefile and
run check successfully on each of them (on Linux). And I've built
LLVMgold.so against the Makefile version and tested it on a simple
test file (the test case from this patch).

However, my patch as it stands combines svn mv operations with edits
on the moved files, so it's far more verbose than necessary and loses
some of the history information (by not exactly capturing the move
information). Would you like me to formulate this as two patches: a
move followed by edits?

Please let me know what you think.

Thanks,

Tom

On Fri, Sep 20, 2013 at 12:50 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> On Fri, Sep 20, 2013 at 12:25:17PM -0700, Tom Roeder wrote:
>> Actually, it looks like libLTO.so simply isn't getting built or found here
>> and that's why the test is failing.
>
> Hm?  The compile log:
> http://lab.llvm.org:8011/builders/clang-X86_64-freebsd/builds/10381/steps/compile/logs/stdio
> seems to indicate that libLTO is being built.
>
> I suspect that the problem is that the rpath isn't being embedded
> in the llvm-lto binary on FreeBSD in the correct way, though I can't
> tell for sure, since I don't have access to a FreeBSD machine.
>
> I'm beginning to think that the right way to solve this problem is
> to move LTOCodeGenerator.cpp and LTOModule.cpp in tools/lto into
> a new component 'lto' in lib/LTO and have tools/lto (which would
> then contain only the C interface) and tools/llvm-lto (and maybe
> tools/gold in the future) depend on the lto component.  That way,
> the LTO support library is no different to any other component of
> LLVM and is less likely to cause problems across platforms.
>
> Thanks,
> --
> Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lib_lto.patch
Type: application/octet-stream
Size: 134157 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130920/1f064e78/attachment.obj>