[llvm-dev] Issue with BUILD_SHARED_LIBS=ON

[David Blaikie via llvm-dev]

Keeping the shared library build working's probably a fine idea, though
working around GCC bugs (depending on how ubiquitous they are) might be
less so.

I'd be fine with this patch going in for this case, though. For a one line
change there's no need to send a phab review, someone (probably me, I
guess) can just apply/commit this directly.

On Fri, Dec 8, 2017 at 1:37 AM Roger Ferrer Ibanez via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Dear all,
>
> while trying to build llvm with shared libraries using GCC (tested both in
> Ubuntu 14.04 and Ubuntu 16.04) as in
>
>   cmake -G Ninja -DBUILD_SHARED_LIBS=ON
>
> I run into the following link error
>
>    lib/Transforms/IPO/CMakeFiles/LLVMipo.dir/PartialInlining.cpp.o: In
> function
> `llvm::ForwardDominanceFrontierBase<llvm::BasicBlock>::ForwardDominanceFrontierBase()':
>    <path>/llvm/include/llvm/Analysis/DominanceFrontier.h:122: undefined
> reference to `llvm::DominanceFrontierBase<llvm::BasicBlock,
> false>::DominanceFrontierBase()'
>
> This change
>
>    diff --git a/include/llvm/Analysis/DominanceFrontier.h
> b/include/llvm/Analysis/DominanceFrontier.h
>    index a304dff..e743d2d 100644
>    --- a/include/llvm/Analysis/DominanceFrontier.h
>    +++ b/include/llvm/Analysis/DominanceFrontier.h
>    @@ -52,7 +52,7 @@ protected:
>       static constexpr bool IsPostDominators = IsPostDom;
>
>     public:
>    -  DominanceFrontierBase() = default;
>    +  DominanceFrontierBase() { }
>
>       /// getRoots - Return the root blocks of the current CFG.  This may
> include
>       /// multiple blocks if we are computing post dominators.  For forward
>
> seems to fix the problem and I think is related to this GCC defect
>
>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
>
> I'm unsure about the level of interest in the community when it comes to
> builds
> using shared libraries.  I personally use them because for debug builds, at
> link time, they are less demanding in memory. However that alone might not
> be
> enough to justify this change as there are valid workarounds (like not
> using
> shared libraries, building clang with clang, using lld, etc).
>
> Thoughts? If this is reasonable I will create a Phabricator.
>
> Kind regards,
> Roger
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171208/aff0a563/attachment.html>