[MLIR] Enabling external dialects to be shared libs for C API users

[makslevental]

Disclaimer: everything below is currently re Linux but Mac/Windows can/should be discussed.

Some people would like to

1. Build MLIR with MLIR_LINK_MLIR_DYLIB=ON;
2. Build external DialectXYZ as a dylib using artifacts of step 1;
3. Runtime load libDialectXYZ.so.

This is actually possible today using DialectPlugin; examples/standalone/standalone-plugin basically demos/exercises this (modulo the MLIR_LINK_MLIR_DYLIB=ON but I've tested with DYLIB=ON too). For C++ API users there are no issues; so e.g., mlir-opt, being a C++ API user, has no problems because mlir-opt and libMLIRStandalone.so will both link against the same libMLIR.so.

What's not possible today is doing this same type of thing through the C API because currently libMLIR-C doesn't link against libMLIR even in the case of MLIR_LINK_MLIR_DYLIB=ON because of some logic I don't quite understand. So today what occurs is

$ ldd libStandaloneCAPI.so
         libMLIRStandalone.so -> libMLIR.so
         libMLIR-C.so

where libMLIR-C.so duplicates everything in libMLIR.so (typeids, etc) and so everything blows up.

What you want is

$ ldd libStandaloneCAPI.so
         libMLIRStandalone.so -┐ 
                               |-> libMLIR.so           
         libMLIR-C.so ---------┘ 

and then everything will work.

Turns out an MVP patch is very small:

diff --git a/mlir/cmake/modules/AddMLIR.cmake b/mlir/cmake/modules/AddMLIR.cmake
index a3324705c525..700a8de26723 100644
--- a/mlir/cmake/modules/AddMLIR.cmake
+++ b/mlir/cmake/modules/AddMLIR.cmake
@@ -410,7 +410,11 @@ function(add_mlir_library name)
     # which excludes it if the ultimate link target is excluding the library.
     set(NEW_LINK_LIBRARIES)
     get_target_property(CURRENT_LINK_LIBRARIES  ${name} LINK_LIBRARIES)
-    get_mlir_filtered_link_libraries(NEW_LINK_LIBRARIES ${CURRENT_LINK_LIBRARIES})
+    if(MLIR_LINK_MLIR_DYLIB)
+      set(NEW_LINK_LIBRARIES "MLIR")
+    else()
+      get_mlir_filtered_link_libraries(NEW_LINK_LIBRARIES ${CURRENT_LINK_LIBRARIES})
+    endif()
     set_target_properties(${name} PROPERTIES LINK_LIBRARIES "${NEW_LINK_LIBRARIES}")
     list(APPEND AGGREGATE_DEPS ${NEW_LINK_LIBRARIES})
     set_target_properties(${name} PROPERTIES

(tested/verified here).

And now I open the floor for discussion; possible topics include:

• Windows and Mac (although I'm not sure if ENABLE_AGGREGATION is supported on Windows?);
• Some alternative approach such as alluded to here https://discourse.llvm.org/t/extensible-standalone-capi/71865/6

cc @vchuravy @mofeing @jumerckx

[llvmbot]

@llvm/issue-subscribers-mlir

Author: Maksim Levental (makslevental)

Disclaimer: everything below is currently re Linux but Mac/Windows can/should be discussed.

Some people would like to

1. Build MLIR with MLIR_LINK_MLIR_DYLIB=ON;
2. Build external DialectXYZ as a dylib using artifacts of step 1;
3. Runtime load libDialectXYZ.so.

This is actually possible today using DialectPlugin; examples/standalone/standalone-plugin basically demos/exercises this (modulo the MLIR_LINK_MLIR_DYLIB=ON but I've tested with DYLIB=ON too). For C++ API users there are no issues; so e.g., mlir-opt, being a C++ API user, has no problems because mlir-opt and libMLIRStandalone.so will both link against the same libMLIR.so.

What's not possible today is doing this same type of thing through the C API because currently libMLIR-C doesn't link against libMLIR even in the case of MLIR_LINK_MLIR_DYLIB=ON because of some logic I don't quite understand. So today what occurs is

$ ldd libStandaloneCAPI.so
         libMLIRStandalone.so -> libMLIR.so
         libMLIR-C.so

where libMLIR-C.so duplicates everything in libMLIR.so (typeids, etc) and so everything blows up.

What you want is

$ ldd libStandaloneCAPI.so
         libMLIRStandalone.so -┐ 
                               |-> libMLIR.so           
         libMLIR-C.so ---------┘ 

and then everything will work.

Turns out an MVP patch is very small:

diff --git a/mlir/cmake/modules/AddMLIR.cmake b/mlir/cmake/modules/AddMLIR.cmake
index a3324705c525..700a8de26723 100644
--- a/mlir/cmake/modules/AddMLIR.cmake
+++ b/mlir/cmake/modules/AddMLIR.cmake
@@ -410,7 +410,11 @@ function(add_mlir_library name)
     # which excludes it if the ultimate link target is excluding the library.
     set(NEW_LINK_LIBRARIES)
     get_target_property(CURRENT_LINK_LIBRARIES  ${name} LINK_LIBRARIES)
-    get_mlir_filtered_link_libraries(NEW_LINK_LIBRARIES ${CURRENT_LINK_LIBRARIES})
+    if(MLIR_LINK_MLIR_DYLIB)
+      set(NEW_LINK_LIBRARIES "MLIR")
+    else()
+      get_mlir_filtered_link_libraries(NEW_LINK_LIBRARIES ${CURRENT_LINK_LIBRARIES})
+    endif()
     set_target_properties(${name} PROPERTIES LINK_LIBRARIES "${NEW_LINK_LIBRARIES}")
     list(APPEND AGGREGATE_DEPS ${NEW_LINK_LIBRARIES})
     set_target_properties(${name} PROPERTIES

(tested/verified here).

And now I open the floor for discussion; possible topics include:

• Windows and Mac (although I'm not sure if ENABLE_AGGREGATION is supported on Windows?);
• Some alternative approach such as alluded to here https://discourse.llvm.org/t/extensible-standalone-capi/71865/6

cc @vchuravy @mofeing @jumerckx

[stellaraccident]

I'm definitely +1 on getting the dylib layering sound here (at least on Linux/MacOS -- I think that all of LLVM's dylib machinery is broken on Windows still). This is in very cold cache for me, though (as a person who has historically wrestled with it). Historically, when I've worked these things, I've had to look very closely at the nm -gDC outputs of all relevant libraries to evaluate soundness (vs "it works", which is usually a very flaky signal). I'd be happy to be another set of eyes on artifacts like that if you have them.

[makslevental]

okay I changed the action to dump nm -gDC for all the libs built along with libStandalone*.so:

https://github.com/makslevental/julia-standalone-mlir-c-api/actions/runs/10820136764/job/30019540687#step:10:382

You're gonna have to view the raw logs because the UI takes forever to load.

ctrl+f for nm standalone-build/lib to jump to the right place.

So what are we looking for as a failure mode for the patch?