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

[Mehdi AMINI via lldb-commits]

mehdi_amini added a comment.

Just to clarify: I don't have a dog in this, I'm just lurking here to learn something, and I'm curious about the tradeoff.

In https://reviews.llvm.org/D26190#585059, @labath wrote:

> In https://reviews.llvm.org/D26190#585016, @mehdi_amini wrote:
>
> > > Does that make sense?
> >
> > This makes sense (assuming static linking reduces some possibility though)
>
>
> I am not sure we are on the same page here. What is the scenario you have in mind here? I am not forbidding anyone from building liblldb linking to libllvm (in fact, I think it should work). I am assuming static linking just because that is the use case most developers use.


Same case as I mentioned below: namespace pollution.

> 
> 
>> , 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?

> 
> 
>> Also, exporting more than the minimum prevent an efficient LTO build of libLLDB.so
> 
> This proposal is about exporting the bare minimum (i.e. lldb namespace).

Yes: this is a good point of this proposal that I was just pointing  (sorry I wasn't clear).

>>> Everything should work fine as long as you don't actually *depend* on having a separate copy of llvm (which is pretty pointless as it does not have global state (apart from the crazy cl globals)).
>> 
>> Is it pointless? Users have dependencies they don't control. I have seen mentioned in the past issues with "symbol pollution" from external library that was affecting LLVM users (a quick search yields https://root.cern.ch/phpBB3/viewtopic.php?f=3&t=22462&sid=dfd0c149390349defea19eb9ce0073c5 )
> 
> Again I think we are misunderstanding each other, the "pointless" was referring to the "relying on global state of libllvm" part of the statement. It seems the problem you quote was caused by a library exporting interfaces it should have kept private, which is what we are doing here (but in your first sentence you seem to indicate you prefer dynamic linking, in which case you cannot hide the symbols (or can you?)).

I don't have any preference (or rather: I prefer static for performance/efficiency reason). I'm more concerned about what use-case exists out-there. Exporting LLVM APIs can cause problem to folks that want/need to build against various third-party.

> 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?


https://reviews.llvm.org/D26190