This results in most MLIR libraries being linked into libLLVM.so
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 43799 Build 44798: arc lint + arc unit
Event Timeline
Are there other LLVM subproject who inject themselves into the global llvm shared library? Should we have a libMLIR.so instead?
Yes I think a libMLIR.so is the right choice, the only reason to go the other way would be if LLVM starts depending on MLIR. A libMLIR.so is a clearer separation and even LTO is split out into its own library.
OK. It looks like to deal with the whole_archive_link line for mlir-opt, this will have to be aware of which libraries are linked into the shared library, so the cmake machinery mostly needs to be there to handle this anyway.
This isn't a possibility to exclude entirely though, it'd be better if we don't add hurdles now to this future possibility.
LTO is split out into its own library.
I believe that this is a different situation: the LTO library is always built as a shared library because it a linker plugin. It also exposes a very specific API for this purpose: it is a different product entirely.
The LLVM shared library on the other hand is an alternative to the static libraries.