<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Apr 14, 2018 at 10:33 PM Weiming Zhao via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">weimingz added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D45244#1064905" rel="noreferrer" target="_blank">https://reviews.llvm.org/D45244#1064905</a>, @dblaikie wrote:<br>
<br>
> Great - thanks for sticking with it, sorry for my dodgy explanations!<br>
><br>
> If you're adding in anchors, are you using -Wweak-vtables to find them? If you're pushing through to make LLVM (& hopefully Clang/other LLVM subprojects) -Wweak-vtables clean, perhaps you can turn on the warning in the CMake config once it's clean so we don't regress this again? (it'd also be interesting to do some kind of analysis to see whether avoiding weak vtables is /actually/ worthwhile - like maybe making a temporary/local/non-committed change to change all the explicit anchors into inline functions (unanchoring them) & see if builds are much larger or longer, etc)<br>
<br>
<br>
I got linker error when my code tries to statically link against some LLVM libs (like libLLVMOrc). It's a good idea to turn on -Wweak-vtables to check if we miss other cases. I will try it. Thanks<br></blockquote><div><br>Hmm, I'm confused - you mean without these changes you were getting link errors due to vtable symbols for types with weak vtables? I'm not sure why that would be - your code should've been built with its own weak vtable, in that situation.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D45244" rel="noreferrer" target="_blank">https://reviews.llvm.org/D45244</a><br>
<br>
<br>
<br>
</blockquote></div></div>