[Lldb-commits] [PATCH] D26190: [RFC] Solve linking inconsistency, proposal two

[Pavel Labath via lldb-commits]

labath added a comment.

In https://reviews.llvm.org/D26190#585106, @mehdi_amini wrote:

> >> , but LLVM is not robust to mix and match build settings: building half of the source with -DNDEBUG and not the other is likely to cause weird runtime failures. That can be an issue because now you need libLLDB built in two modes and the client app to link the right one.
> > 
> > I don't see how this applies. This is true when you build liblldb, and it's true that lldb's assertion settings need to match llvm's, but since liblldb's api is stable wrt. N/_DEBUG, it's user should not need to care about that.
>
> It applies at the moment you consider that the client code does not need to link to LLVM because LLDB provides a copy. It means that now, even if it is not relevant for the LLVM interface, the client code needs to be built with the same configuration as the libLLDB shared lib.
>
> Not exposing LLVM but only the minimal non-LLVM API prevents the client code from using any LLVM symbol from libLLDB, and thus makes it possible to mix-n-match a release build of libLLDB with an assert built client code.
>
> Make sense?


Ok, so you were pointing out a flaw in the first proposal, not this one. I think that's the part I missed.

Yes, If we exported the llvm interface, the user could not use a different version of llvm elsewhere in the program. The thing is, the user is not supposed to do that anyway, as it violates the One Definition Rule of c++:

  §4: Every program shall contain exactly one definition of every non-inline function or variable that is odr-used
  in that program; no diagnostic required. [...]
  §6: There can be more than one definition of a class type (Clause 9), enumeration type (7.2), [list of other kinds of entities] in a program provided that each definition appears in a different translation unit, and provided the definitions satisfy the following requirements. Given such an entity named D defined in more than one translation unit, then:
  - each definition of D shall consist of the same sequence of tokens; and
  - [...]

The last part fails as soon as mix different NDEBUG versions. We can make that work by not exporting the llvm interface, but then it's not really C++. :) And it can break in case you don't know what you are doing (occasionally you see people statically linking the standard c++ library into a part of their project and then marveling at the results).

This is why I wanted to propose both, although at this point I think I have convinced myself as well than the first one wasn't a good idea.

>> I think you'll have to repeat your point, as now I am totally confused about what you are trying to say. :)
> 
> Sorry, I hope it is more clear now?

Thanks. :)


https://reviews.llvm.org/D26190