<div dir="ltr">I see.  Yea, that makes sense. <br></div><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 2:43 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The problem is that lldb explicitly #defines and #undefs NDEBUG before<br>
including clang/llvm headers, and it does so inconsistently.  From my<br>
earlier mail:<br>
<br>
'''<br>
As an example, ClangASTType.h will include clang headers without<br>
#defining NDEBUG while ClangExternalASTSourceCommon.h will include<br>
clang headers *after* #defining NDEBUG.<br>
'''<br>
<br>
So you can end up with a copy of InsertIntoBucketImpl compiled with<br>
NDEBUG set in one TU and without NDEBUG set in another TU.  If a call<br>
to InsertIntoBucketImpl in the latter gets linked to the definition of<br>
InsertIntoBucketImplin the former, then you're in trouble.  This is<br>
what is happening, as far as I can tell.<br>
<br>
Did I understand your question correctly?<br>
<br>
-- Sanjoy<br>
<br>
On Wed, Mar 4, 2015 at 2:35 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> I'm still a little confused about why I was getting the same issue on<br>
> Windows.  I can understand if someone uses LLVM as a library and they use,<br>
> for example, a release version of clang/llvm but a debug version of LLDB.<br>
> But I didn't do that.  I build LLDB the same way anyone else builds clang or<br>
> any other subproejct.  I use CMake with -DCMAKE_BUILD_TYPE=Debug, then run<br>
> ninja, and that's it.  So I should have the same value of NDEBUG for both<br>
> projects, and still I was getting the error.<br>
><br>
> On Wed, Mar 4, 2015 at 2:29 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.<u></u>com</a>><br>
> wrote:<br>
>><br>
>> > A separate define seems like the best we can do. The downside is that we<br>
>> > can't turn this on by default in a standard +Asserts build, or we've<br>
>> > just<br>
>> > moved the ABI incompatibility problem to a different define.<br>
>><br>
>> This may be the most practical solution so far, but I dislike it<br>
>> because it means a default +Asserts build won't get the kind of<br>
>> verification it can and should.<br>
>><br>
>> -- Sanjoy<br>
</blockquote></div>