Here are my notes on the remaining TypeID weak linkage instances. For robust C++ dynamic linking, they all need to be fixed: More work needed for TypeID duplication (help wanted)
We are using the Python bindings in some quite advanced, cross project ways, but we never do C++ dynamic linking. Instead, each project embeds what it needs of the API and the cmake machinery creates a combined CAPI .so/.dll and everything links to that. It would be nice to have better support for general C++ dynamic linking on MLIR, but this case (hermetic, CAPI-based Python extensions) is the preferred way for a number of deployment scenarios, and it carefully threads the needle across all of the platforms regarding link-time/dso designs to be sound (i.e. IREE, CIRCT and Torch-MLIR are deploying Python extensions that include the MLIR API+other projects like MHLO for both Linux/Windows/MacOS).
I would like to see the rest of the issues I noted above fixed, but I don’t have the time right now to track them all down.
Given what I know, it sounds like you may be holding something wrong. Could you share more about your CMake flags and setup? Specifically, it sounds like you are doing a DYLIB/shared build – and afaict, that should be an unsupported configuration for MLIR until more of the dynamic linkage issues are resolved (my personal opinion/experience).