[llvm] r337366 - [CMake] Export the LLVM_LINK_LLVM_DYLIB setting

Philip Pfaffe via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 24 05:07:38 PDT 2018


In that case I believe it should suffice to check whether an LLVM target
exists. Then it's up to you to pick the right dependency. But out of tree
clients which depend on e.g. LLVM and libclang, that's not a nice default.

On Tue, Jul 24, 2018 at 1:56 PM Pavel Labath <labath at google.com> wrote:

> Yes, for that particular configuration it wouldn't work. However, if
> one is an external project which does not use clang (for example,
> clang itself), then one should be free to choose whether to link to
> the monolithic lib or not. (I think, I am now not sure whether the
> static libs get installed if you say you want to build the monolithic
> dylib)
> On Tue, 24 Jul 2018 at 12:49, Philip Pfaffe <philip.pfaffe at gmail.com>
> wrote:
> >
> > I haven't tried it yet, but wouldn't that give me duplicate symbols/cl
> options when linking against libLLVM _and_ a clang library linked
> statically?
> >
> > On Tue, Jul 24, 2018 at 1:33 PM Pavel Labath <labath at google.com> wrote:
> >>
> >> I don't think I know all the implications of this, but would it be
> >> possible to export LLVM_**BUILD**_LLVM_DYLIB instead of this option?
> >> That way, the external projects will still be able to determine
> >> whether the library exists at all, but they will have the option to
> >> independently control whether they want to link to it or not?
> >> On Tue, 24 Jul 2018 at 11:55, Philip Pfaffe <philip.pfaffe at gmail.com>
> wrote:
> >> >
> >> > I can reproduce the not-linking-with-dylib bit, but it doesn't fail
> during linking for me. That's why I missed this in testing. Sorry!
> >> >
> >> > Is this serious enough to revert to unbreak you?
> >> >
> >> > Alternatively there's two quick fixes for this:
> >> > - Make LLVM_LINK_LLVM_DYLIB an option() in LLVMConfig.cmake. Then
> it'll show up in the GUI and respects configurations.
> >> > - Wrap the set() in an if().
> >> >
> >> > I'd prefer going the option() route. Adding a CLANG_LINK_LLVM_DYLIB
> additionally is worth considering, I'd prefer doing that as a seperate
> change though.
> >> >
> >> > Cheers,
> >> > Philip
> >> >
> >> > On Tue, Jul 24, 2018 at 1:30 AM Justin Bogner <mail at justinbogner.com>
> wrote:
> >> >>
> >> >> Philip Pfaffe via llvm-commits <llvm-commits at lists.llvm.org> writes:
> >> >> > Author: pfaffe
> >> >> > Date: Wed Jul 18 01:53:31 2018
> >> >> > New Revision: 337366
> >> >> >
> >> >> > URL: http://llvm.org/viewvc/llvm-project?rev=337366&view=rev
> >> >> > Log:
> >> >> > [CMake] Export the LLVM_LINK_LLVM_DYLIB setting
> >> >> >
> >> >> > Summary:
> >> >> > When building out-of-tree tools, there are several macros
> available to
> >> >> > automate linking against llvm. An examples is
> `add_llvm_executable`, or
> >> >> > the clang variant of this.
> >> >> >
> >> >> > These macros use the LLVM_LINK_LLVM_DYLIB option to decide whether
> to
> >> >> > link against libraries defined by setting LLVM_LINK_COMPONENTS or
> to
> >> >> > link against libLLVM instead. Currently this is problematic in
> >> >> > out-of-tree targets, because they cannot identify whether this
> option is
> >> >> > required or even available. If the option was enabled in LLVM's own
> >> >> > build, the clang libraries are built against libLLVM, so a client
> >> >> > linking against those must link against it too. On the other hand
> the
> >> >> > client can't just always link against it, because it might not be
> >> >> > available.
> >> >>
> >> >> I'm not sure I understand the problem this is solving, but it breaks
> the
> >> >> case where an out-of-tree target tries to link the dylib when the
> >> >> in-tree build does not. Specifically, if I build llvm with
> >> >> LLVM_LINK_LLVM_DYLIB=Off (but LLVM_BUILD_LLVM_DYLIB=On), and then I
> try
> >> >> to build clang against this with LLVM_LINK_LLVM_DYLIB=On, clang's
> >> >> setting of the variable seems to be ignored and I get link errors as
> it
> >> >> looks for static libraries.
> >> >>
> >> >> Can this be made to respect externally setting the variable? Maybe it
> >> >> should only show up if set, for example? Alternatively, do external
> >> >> projects need to implement their own version of the variable, like a
> >> >> CLANG_LINK_LLVM_DYLIB?
> >> >>
> >> >> > This is related to D44391, but that change assumed the client knew
> >> >> > whether they wanted the dylib or not.
> >> >> >
> >> >> > Reviewers: mgorny, beanz, labath
> >> >> >
> >> >> > Reviewed By: mgorny
> >> >> >
> >> >> > Subscribers: bollu, llvm-commits
> >> >> >
> >> >> > Differential Revision: https://reviews.llvm.org/D49193
> >> >> >
> >> >> > Modified:
> >> >> >     llvm/trunk/cmake/modules/LLVMConfig.cmake.in
> >> >> >
> >> >> > Modified: llvm/trunk/cmake/modules/LLVMConfig.cmake.in
> >> >> > URL:
> >> >> >
> http://llvm.org/viewvc/llvm-project/llvm/trunk/cmake/modules/LLVMConfig.cmake.in?rev=337366&r1=337365&r2=337366&view=diff
> >> >> >
> ==============================================================================
> >> >> >
> >> >> > --- llvm/trunk/cmake/modules/LLVMConfig.cmake.in (original)
> >> >> > +++ llvm/trunk/cmake/modules/LLVMConfig.cmake.in Wed Jul 18
> 01:53:31 2018
> >> >> > @@ -13,6 +13,8 @@ set(LLVM_COMMON_DEPENDS @LLVM_COMMON_DEP
> >> >> >
> >> >> >  set(LLVM_AVAILABLE_LIBS @LLVM_AVAILABLE_LIBS@)
> >> >> >
> >> >> > +set(LLVM_LINK_LLVM_DYLIB @LLVM_LINK_LLVM_DYLIB@)
> >> >> > +
> >> >> >  set(LLVM_DYLIB_COMPONENTS @LLVM_DYLIB_COMPONENTS@)
> >> >> >
> >> >> >  set(LLVM_ALL_TARGETS @LLVM_ALL_TARGETS@)
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > llvm-commits mailing list
> >> >> > llvm-commits at lists.llvm.org
> >> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180724/1a61e6f3/attachment.html>


More information about the llvm-commits mailing list