Installing Mica

The Mica compiler is a single statically linked executable plus its standard library. It has no runtime of its own to install and no daemon to run.

Zero-install: the container

If Docker is available, nothing needs installing at all — the released compiler ships as a ready-to-use image for both x86-64 and ARM64, and docker pull selects your architecture automatically. New to Mica? The guided version of this path — empty folder to source-level debugging in fifteen minutes — is Get started with Mica.

docker run -it micalang/mica

The image carries the compiler, binutils, gdb and git, so compiling, running and debugging work immediately; C toolchains for work at the C boundary are one command away inside the container (mica-provision gcc, mica-provision llvm). Before your first commit, tell git who you are, once: mica-provision git --git-name "Your Name" --git-email you@example.com.

It is also a ready-made VS Code dev container: with the Mica extension you get diagnostics, go to definition, hover and the document outline, and F5 compiles and debugs the file you have open under gdb. Get started with Mica writes the one-file container description that opens a project of your own in the image; the starter repository, gitlab.com/mica-dev/mica-container, is the quickest first experiment, with every example ready to build. The image’s Dockerfile lives in the same repository.

Everything below is the native installation.

What you need

Two system packages, and nothing else:

On Debian or Ubuntu the packages pull both in automatically:

sudo apt install ./mica_<version>_<arch>.deb ./mica-dragon-rt_<version>_<arch>.deb

The compiler binary itself is statically linked, so it has no library dependencies of its own — the two packages above are for the programs it produces, not for running the compiler.

Supported systems. 64-bit Linux with glibc 2.38 or newer — Debian 13, Ubuntu 24.04 and every later release — on x86_64 (x86-64-v3 or later — Intel Haswell, AMD Zen) or AArch64 (ARMv8.0-A). The packages state that C library as a dependency, so an older system is refused when they install. There is no Windows or macOS build; see platform and toolchain.

Download

Version 7.7.7, built from commit f3ea65b78. Verify a download with sha256sum against the hash above.

Install

# from the directory holding both .deb files
sudo apt install ./mica_<version>_<arch>.deb ./mica-dragon-rt_<version>_<arch>.deb

The compiler depends on mica-dragon-rt — the Dragon runtime its programs link — so the two install as one act; apt resolves binutils and libc6-dev for you. If you use dpkg directly, install the dependencies afterwards:

sudo dpkg -i mica_<version>_<arch>.deb mica-dragon-rt_<version>_<arch>.deb
sudo apt-get install -f

Optional: the sanitized runtime

To link a program under a C sanitizer with --sanitize, so the C beneath it runs checked, install the Dragon runtime built under the sanitizers as well. It depends on gcc, whose packages bring the sanitizer runtimes, and no other build needs it:

Version 7.7.7, built from commit f3ea65b78. Verify a download with sha256sum against the hash above.

sudo apt install ./mica-dragon-rt-sanitizers_<version>_<arch>.deb

Check it worked

mica --version

Then compile something. Save this as Hello.mica:

program Hello;

imp
    WriteLn : std;

begin
    WriteLn("hello from mica");
end.

and build it:

mica --compile --link --optimize release,full_optimizations --source Hello.mica --build build
./build/Hello

You should see hello from mica. The compiler builds for the machine it runs on, x86-64 or AArch64, unless --platform names the other one.

What gets installed

Installing mica also installs mica-dragon-rt, the Dragon runtime — the floor every compiled program links, packaged separately because the same floor serves programs produced by any compiler built on the Dragon backend. On disk, the pair looks like this:

/usr/bin/
└── mica                                       the compiler driver        (mica)

/usr/lib/
├── mica-stdlib-<arch>.a                       the standard library       (mica)
├── mica-dragon-rt-<arch>.a                  the Dragon runtime         (mica-dragon-rt)
├── mica-dragon-rt-fixedarena-<arch>.a         … freestanding memory class
├── mica-dragon-rt-mc-<arch>.a                 … multicore tasking
├── mica-dragon-rt-fixedarena-mc-<arch>.a      … both
├── mica-dragon-rt-sites…-<arch>.a             … the same four again, built to record each cell's
│                                                allocating site; a debug-tier build links these
├── libmica-dragon-rt…-<arch>.so.<release>     … the same eight as shared objects, the floor
│                                                every Mica shared object names
└── mica-dragon-gpu-<arch>.a                   the device floor, linked when a tensor is placed on gpu

/usr/libexec/mica/
└── mica-precompile-nvidia-<arch>              the GPU kernels' precompiler, which the compiler runs (mica)

/usr/share/doc/
├── mica/copyright                             Mica Compiler License 1.0
└── mica-dragon-rt/copyright                   Mica Runtime License 1.0

Every archive and shared floor under /usr/lib/ is there twice, once for each architecture (amd64 and arm64), so a build for the other architecture finds its standard library and runtime exactly where the machine’s own are.

You do not normally name any of these. The compiler resolves the right archives from the --platform, --memory-class, --tasking and --optimize you ask for. Both are static: a compiled program carries everything of Mica’s inside it, and the machines it runs on need no Mica package at all.

The Dragon SDK — the compiler’s backend as a C API, for building your own language on it — is a separate package under a different licence, with its own download and install page. The compiler alone will happily compile a program that imports the dragon surface — only the link asks for the SDK’s archive, and says so by name if it is not there.

The interop contracts and the standard library’s published import surfaces are part of the compiler binary and are not installed separately.

Removing Mica takes all of it away again, together with the files the compiler and the editor leave behind while you work.

One thing that catches people out

The string encoding is fixed per binary, and the format specifier follows it. Under utf-8 a string is %s; under utf-32 it is %ls. Get it wrong and the compiler tells you exactly which specifier it expected — it checks format strings at compile time rather than letting a mismatch reach the output.

Building for the other architecture

The packages carry both architectures’ standard library and runtime, so producing an AArch64 binary on an x86_64 machine, or the reverse, needs only that architecture’s binutils and C library, plus a user-mode emulator to run the result. On an x86_64 machine:

sudo apt install binutils-aarch64-linux-gnu libc6-dev-arm64-cross qemu-user-binfmt
export QEMU_LD_PREFIX=/usr/aarch64-linux-gnu

On an AArch64 machine the same three are binutils-x86-64-linux-gnu, libc6-dev-amd64-cross and qemu-user-binfmt, with QEMU_LD_PREFIX=/usr/x86_64-linux-gnu. The starter repository’s devkit installs them in one command, devkit/mica-provision mica qemu.

Then name the target architecture in --platform:

mica --compile --link --optimize release,full_optimizations \
     --platform linux,arm64,utf-8 \
     --source Hello.mica --build build
./build/Hello

The binary runs through the emulator, which the kernel starts for it.

See also

• Installing the Dragon SDK — the backend as a C API, a separate package under its own licence
• Removing Mica — the packages, the extension, the container and every file Mica leaves, taken away again
• Platform and toolchain — targets, ABIs, build axes
• The facts sheet — every fact on one page, the AI surface included
• Licensing — free for any use, including commercial