[PATCH] D129116: ManagedStatic: remove from DebugCounter

[Nicolai Hähnle via Phabricator via llvm-commits]

nhaehnle added a comment.

Thanks, I can reproduce this now. I was using LLD, and that behaved differently from ld.bfd.

I dug into it now. It's a hairy tangle. There are, among other things, the following relevant dependencies that I found:

  mlir-pdll-lsp-server -> MLIRPDLLParser --(static)--> LLVMSupport
  mlir-pdll-lsp-server -> MLIRPDLLParser --> MLIRSupport --(dynamic)--> LLVMSupport
  mlir-pdll-lsp-server -> MLIRLspServerSupportLib --> MLIRSupport --(dynamic) --> LLVMSupport    ; last dependency implicit from add_mlir_library
  mlir-lsp-server -> MLIRLspServerLib --> (lots of MLIR libraries) --> MLIRSupport --(dynamic)--> LLVMSupport
  mlir-lsp-server -> MLIRLspServerLib --> MLIRLspServerSupportLib --> (see above)
  mlir-pdll -> MLIRPDLLParser --> (see above)
  mlir-tblgen --(static)--> LLVMSupport

So to try and sum it up:

- mlir-lsp-server really "wants to" link dynamically to LLVMSupport
- mlir-pdll-lsp-server shares MLIRLspServerSupportLib with mlir-lsp-server, and so really also "wants to" link dynamically to LLVMSupport, but is broken because MLIRPDLLParser is confused about static vs. dynamic linking
- mlir-pdll shares MLIRPDLLParser with mlir-pdll-lsp-server, and so maybe also "wants to" link dynamically to LLVMSupport? But it, too, is confused, plus it's a tablegen-style tools which are traditionally statically linked

How important is it actually to try to avoid having these tools link against libLLVM-*.so? Upon reflection, I don't actually understand why. Initially, I thought this is for native llvm-tblgen and clang-tblgen builds when cross-compiling: we don't want these to depend on libLLVM-*.so. But then, during cross-compilation the native build works by executing cmake recursively, so can't the recursive cmake invocation just force LLVM_LINK_LLVM_DYLIB=OFF?

So my feeling is that the least painful solution in the long run is to just get rid of all the DISABLE_LLVM_LINK_LLVM_DYLIB for tablegen-y tool, starting in MLIR but eventually propagating that change to other parts of llvm-project. Would that be okay for MLIR? I can take a stab at it, there are some more dependencies that would have to be taken care of first.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129116/new/

https://reviews.llvm.org/D129116