thr3ads.net - llvm dev - [llvm-dev] Issue with BUILD_SHARED

If this information is useful, please help other people find it:
Share via:

Roger Ferrer Ibanez via llvm-dev

2017-Dec-08 09:37 UTC

[llvm-dev] 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

   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

David Blaikie via llvm-dev

2017-Dec-08 18:04 UTC

head link

[llvm-dev] Issue with BUILD_SHARED_LIBS=ON

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>

Roger Ferrer Ibanez via llvm-dev

2017-Dec-08 18:55 UTC

head link

[llvm-dev] Issue with BUILD_SHARED_LIBS=ON

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

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: 08 December 2017 18:05
To: Roger Ferrer Ibanez
Cc: llvm-dev; nd
Subject: Re: [llvm-dev] Issue with BUILD_SHARED_LIBS=ON

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<mailto: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<mailto: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/80b6d580/attachment.html>

Jakub (Kuba) Kuderski via llvm-dev

2017-Dec-08 19:02 UTC

head link

[llvm-dev] Issue with BUILD_SHARED_LIBS=ON

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

On Fri, Dec 8, 2017 at 1:04 PM, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
Jakub Kuderski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171208/c000b689/attachment.html>

llvm dev - Dec 2017 - Issue with BUILD_SHARED_LIBS=ON

[llvm-dev] Issue with BUILD_SHARED_LIBS=ON

[llvm-dev] Issue with BUILD_SHARED_LIBS=ON

[llvm-dev] Issue with BUILD_SHARED_LIBS=ON

[llvm-dev] Issue with BUILD_SHARED_LIBS=ON