[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

labath added a comment. Ok, I guess we're leaning towards option two then, which is more-or-less status quo as well. I am going to leave this open for a while in case anyone has more input. Todd, for you this means that you cannot export *all* symbols from liblldb, as that would break the link

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

zturner added a comment. BTW, in general static linking on Windows is "bad", but as long as no SBI API header directly or indirectly includes an LLVM header, and there is no LLVM usage on the API boundary, it should be ok IIUC. https://reviews.llvm.org/D26188 ___

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

labath added a comment. In https://reviews.llvm.org/D26188#584710, @zturner wrote: > On Windows if you have a DLL (.so) that links against a .lib (.a), and an EXE > links against both the DLL and the .lib, then both the DLL and the EXE will > each get their own private copy of the symbols in th

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. I would rather not see us export everything in LLVM. The gentleman's agreement doesn't enforce anything and this will cause crashes when people try to launch a tool against a dif

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

zturner added a comment. On Windows if you have a DLL (.so) that links against a .lib (.a), and an EXE links against both the DLL and the .lib, then both the DLL and the EXE will each get their own private copy of the symbols in the lib, and the linker won't try to merge them. Do I understand

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

labath added a comment. I thought removing it will cause it to export everything. If it doesn't, then we can put whatever magic is necessary there. :) Although, if exporting everything does require some fancy linker flags, then I probably wouldn't make it the default. https://reviews.llvm.org

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

tfiala added a comment. > @zturner wrote: > Can I have some background? What is the linking problem? Hi Zachary, This review has comments that pretty much cover it exhaustively: https://reviews.llvm.org/D26093 That'd be a good place to start. https://reviews.llvm.org/D26188 __

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

tfiala added inline comments. Comment at: source/API/CMakeLists.txt:109 else() -# Don't use an explicit export. Instead, tell the linker to -# export all symbols. > This does not affect affect the state of backtracing. The option to export > all symb

Re: [Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

See . Basically the problem is that we are pulling in llvm symbols twice into lldb-mi (once in liblldb, and once in lldb-mi proper). This was causing runtime errors if we did not have the "linker firewall" in place. I am proposing to either make sure things build w

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

labath added a comment. In https://reviews.llvm.org/D26188#584614, @tfiala wrote: > I'll let Greg comment on the public ABI expansion (i.e. including llvm of a > specific version, which may differ from LLDB.framework clients that contain > different versions of LLVM). My guess is this is not g

Re: [Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

Can I have some background? What is the linking problem? On Tue, Nov 1, 2016 at 8:16 AM Todd Fiala wrote: > tfiala added a comment. > > I'll let Greg comment on the public ABI expansion (i.e. including llvm of > a specific version, which may differ from LLDB.framework clients that > contain diffe

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

tfiala added a comment. I'll let Greg comment on the public ABI expansion (i.e. including llvm of a specific version, which may differ from LLDB.framework clients that contain different versions of LLVM). My guess is this is not going to work for us, since we have long-lived frameworks shipped

[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

labath created this revision. labath added reviewers: beanz, zturner, tfiala, clayborg, abidh. labath added a subscriber: lldb-commits. Herald added subscribers: mgorny, ki.stfu. This solves the ODR violations by exporting all symbols in the llvm namespace to all users of liblldb, which can then a