[arcillator] Arcillator Can't be built Fully Static

[seldridge]

I ran into this when trying to build a fully static firtool while also running tests. The problem that I hit was that arcillator wants to statically link a .so:

/usr/lib/gcc/x86_64-alpine-linux-musl/14.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: attempted static link of dynamic object `lib/libarc-jit-env.so'

Full build log:

https://github.com/llvm/circt/actions/runs/14545811276/job/40811100200#step:9:4754

[fabianschuiki]

I'm wondering how we should deal with these dynamic objects that are loaded by the JIT environment. I think these have to be dynamic to be loadable. Ideally we'd be able to statically link what they need into them, to make them self-contained… but this error looks like that's not possible 🤔 @maerhart @dtzSiFive do you have any idea how we could deal with *.sos in statically-linked builds?

[maerhart]

Yeah, this has to be always dynamically linked. Looks like some dependency is set up incorrectly.

Don't we have to remove arc-jit-env here and instead just add it as a dependency in the test directories and pass it via the shared-libs argument to an arcilator call? Ideally install it in some default directory and add that as a default to that flag?

If that doesn't work maybe we also need something like MLIR's EXCLUDE_FROM_LIBMLIR (https://github.com/llvm/llvm-project/blob/901ac60db7d864c79aa34d93fc46f2635e3afd50/mlir/lib/ExecutionEngine/CMakeLists.txt#L67)? Not sure what exactly that does but it's added to all the MLIR runtime library declarations.

[fabianschuiki]

I'm wondering why this is even built as a dynamic object. I would assume that Arcilator itself would already be linked against the necessary support stuff that the JITed code might want to call, so that could also be a static link (I think). And if someone uses Arcilator to produce a simulation model they can always link against the arc-jit-env library statically!

[fzi-hielscher]

One of the reasons I decided not to link the runtime library statically against the arcilator executable was to avoid problems regarding the visibility of symbols. The behavior here differs between platforms and possibly linkers, and if the executable does not export the symbols of the runtime lib, the JIT runner won't find them. So a dynamic lib seemed like the safer option to me.
Also, conceptually I think it makes more sense as a dynamic library.

The arcilator tool calls the initialization routine of the runtime library (https://github.com/llvm/circt/blob/main/tools/arcilator/arcilator.cpp#L449), so there is a link-time dependency between them. I don't have access to all my systems right now, but I'll check if I can fix this in the coming days.

Given that the only thing that uses the runtime library at the moment is its own test, feel free to just kick it out if it is an urgent problem.