nix-eda-packaging

Nix EDA Packaging

Overview

EDA tools are awkward Nix citizens: they dlopen plugins at runtime, expect data files at fixed paths, and ship as prebuilt binaries with bad assumptions about the filesystem. The temptation is to paper over each failure with a wrapper or a binary patch. The discipline is to fix the actual dependency so the package is honest about what it needs.

Core principle: Make the package's real dependencies explicit, don't disguise them. A wrapProgram that injects a path or a patchelf that rewrites an interpreter hides a missing dependency instead of declaring it, and it breaks the next person who builds on your package.

When to Use

• Packaging Yosys, OpenROAD, a simulator, or a vendor EDA binary in Nix
• A tool fails at runtime to dlopen a plugin or find a shared library
• Writing derivations and build phases for hardware tooling
• Building/evaluating on aarch64-linux

Don't Reach For The Hacks

These are the moves to avoid, and what they're hiding:

• wrapProgram to inject LD_LIBRARY_PATH / plugin paths. Hides a real missing runtime dependency. The library belongs in buildInputs and on the proper rpath, or the plugin belongs in a declared search path the program already honors.
• patchelf to rewrite the interpreter or rpath by hand. Hides a build that didn't link correctly. Fix the link, or for unbuildable prebuilt blobs use the proper mechanism (autoPatchelfHook) only as a last resort and only for genuinely closed binaries, not to dodge a dlopen issue in something you build from source.
• autoPatchelfHook as a dlopen fix. It patches NEEDED entries; it does not solve a runtime dlopen("libfoo.so") that searches a path you haven't set up. Reaching for it here means you're treating the wrong layer.

When a dlopen fails, find what the tool actually dlopens and at what path, then provide that path the way the tool expects (a real search path, a data dir, an env the program documents) rather than wrapping the binary.