Issue with BUILD_SHARED_LIBS=ON

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

   57728 – Explicit template instantiation with defaulted method causes missing symbol

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

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.

Hi David,

I can commit it but I wanted first to double-check that it was a sensible thing to do.

Thank you very much,

Roger

Hi Roger,

I think it was me who introduced the change from () { } to () = default for a couple of dominators-related classes during the major refactoring I did in the summer. We got reports of very similar compiler/linker failures with gcc and older versions of clang, and I thought I reverted most of them to () {} as a workaround. Fell free to do the same with this one.

Best regards,
Kuba