[PATCH] request for approval to commit: llvm-c: Make target initializer functions external functions in lib.

[Filip Pizlo]

On Sep 30, 2013, at 12:51 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>> Would you then also have a libLLVMAllTargets.a?
> 
> I don't think it would be necessary. Given how .a files work the .o
> defining LLVMInitializeAllTargetInfos would not be fetched if that
> function is not called.

Good point!

Yeah, I think that what the patch needs is AllTargets.cpp.

-Filip

> 
>> I mean, it seems like it would work, but I just want to make sure I'm on the
>> same page as you about why this is better than what LLVM does today.  For
>> programs that already build against all of LLVM's targets, presumably they
>> do it by static linkage - in which case what LLVM trunk does right now is
>> fine:  llvm-config will tell you to link all of the .a's, and the header
>> file will have that static inline function that initializes all of the
>> targets.  It works for those use cases, and it also allows cherrypicking: a
>> client can ignore part of the --libs list from llvm-config and then
>> initialize targets directly.
>> 
>> So, having AllTargets.cpp would mainly be beneficial for those who build
>> LLVM as a single shared library, rather than as static libraries.  Is that
>> what we're going for here?
> 
> Yes. The problem is that right now a program using llvm as a shared
> lib gets undefined references to
> 
> LLVMInitializeR600Target
> LLVMInitializeSparcTarget
> LLVMInitializeMSP430Target
> ...
> 
> A program compiled against an older version would have an undefined
> reference to LLVMInitializeMBlazeTarget and would not load with a
> current llvm built as a shared library.
> 
> Cheers,
> Rafael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130930/cc06e5e1/attachment.html>