[PATCH] request for approval to commit: llvm-c: Make target initializer functions external functions in lib.
rafael.espindola at gmail.com
Mon Sep 30 12:51:20 PDT 2013
> 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.
> 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
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.
More information about the llvm-commits