Trying to get MLIR_LINK_MLIR_DYLIB implemented


I’m finally starting to try to package MLIR for Gentoo. As part of that, I’d like to use dynamic linking as far as possible and to avoid installing any static libraries at all.

From what I can see, MLIR includes a MLIR-C dylib, as well as a MLIR_LINK_MLIR_DYLIB switch alike clang. However, the switch doesn’t seem to be implemented at all. I gave implementing it a shot and… for a few tools from mlir/tools directory, the dylib was far from sufficient because of how many MLIR libraries are excluded from it.

I’ve tried doing a combined linking with MLIR-C and the remaining static libraries but it’s a linking nightmare. Besides, given how many libraries end up being used in different tools, the resulting executables would be huge anyway.

Right now, I have two possible solutions in mind: either including all MLIR libraries in MLIR-C, or creating a second dylib for the remaining libraries that mlir tools can use (and having it linked to MLIR-C). WDYT?


I knew this would come back to bite us. Not sure if it helps, but the MLIR-C library is intended to be somewhat like the LLVM re-export C library (which is optional). The wonky part here is that the C API is only exported from the MLIR-C API, not from the underlying MLIR dylib. Every time I’ve looked at the latter, I’ve gotten very sad because I just can’t see how it is ever actually going to be good. I had intended to come back and layer this better but we were blocked on the TypeID bug making anything better impossible (it effectively makes cross DSO linking if MLIR c++ code impossible). I believe that is fixed (or mostly so) at this point, so we can in theory fix the library layering now.

My opinion is that we need to deprecate entirely, instead creating more shared libraries. I’d like to see a libMLIRCore that contains the core infra and supporting C API. Then some set of shared libraries for the dialects – up to one per dialect (but there may be some groupings that make sense). That will be a disruptive bit of work that I don’t have time for right now but might be able to help in December. I think I laid some of the groundwork for this but would need to refresh my memory.

That doesn’t help your immediate goals. I’d be inclined to say that for packaging today we should only do static linking with an MLIR-C library, and that we do a project to get dynamic linking done right vs baking the current state everywhere. I know that isn’t great.

If static linking is the only option, then I’m afraid that packaging MLIR in Gentoo is a no-go, and this in turn blocks flang further. I don’t even want to start with static libraries because replacing them with dylib afterwards is really painful when every other project relies on them in unpredictable ways.

Yeah, I get it. What’s your timeline? I think the answer right this minute is to disable the MLIR-C library and put more pressure on libMLIR alone. That is not a great option and we need to fix this. I’m somewhat wary of creating a bigger linking issue with adventurous attempts to combine these things without doing it in a more principled/sustainable way.

Well, as long as clang, LLD and other components we already packaged don’t require MLIR, I suppose there’s no hurry. However, I’m on vacation right now, so I have more time to help out.

Why does it block flang? Can’t you statically link MLIR into flang and not ship an MLIR package on gentoo?

1 Like

I doubt that’s possible, at least without humongous hacks.

Is this because you are building flang with shared libraries itself?
I mean right now the default build should produce a statically linked flang binary already.

Is it because you have flang linking a libLLVM shared library? (But even this I am not sure it is a fundamental issue that prevents putting the mlir code instead the flang binary)

Rather because I’m trying to build MLIR and flang standalone, so I guess I’d have to install MLIR first. Installing MLIR would imply exposing the static libraries which is precisely what I’m trying to avoid. Not to mention all MLIR tools are huge due to static linking.

In this case could you disable building the tools and install only the MLIR archives for the purpose of building flang?
Some getting the flang wheels would not need MLIR at all.

This would still expose MLIR archives to the users, effectively meaning in the next days someone’s gonna start depending on them and I’ll be stuck with the dependency hell.

I don’t understand this sentence.

Sorry I haven’t used gentoo in a decade :slight_smile:
By wheels I meant prebuilt binaries for flang (that exists in gentoo?)
Can you build the MLIR static archives as part of the recipe to build flang? As transitive artifacts of the build and not as a package that the users gets exposed to?
Basically : don’t build flang from “standalone” sources?

Gentoo does not distribute official prebuilt packages.

Hmm, I suppose that could work, though I would qualify that as a hack of medium size.

Any chance you can build dynamic and only install flang for now (not headers/tools and such)? Until some work is done, I’ll claim that shared library API builds are going to be a real battle. I’m interested in doing a sprint to fix this up right but just don’t have the time right this minute.

1 Like

I’m sorry, could you explain what you mean by “building dynamic”?

Get something like MLIR_LINK_MLIR_DYLIB working for flang and install flang, not including the MLIR libraries and tools for now.

Hmm, that’s an interesting option. I’ll look into that, thanks!

Just wanted to add my +1 on this topic.

Haven’t started building flang for conda-forge yet (though pretty high on my FOSS todo list), and being able to base that on shared MLIR builds would be important (though not make-or-break) to us as well.

1 Like

Afaik, flang depends on a small amount of MLIR. How much do you care about looking to s shared library that has “everything” vs more contained dependencies (ie. A core library and a couple of dialects)?

I’m wondering what’s the performance impact there as well? That is the performance of the statically linked flang or clang vs dynamically linking? Also static linking for these binaries opens up to (Thin)LTO, PGO, Bolt, …