How to Install the Solidity Compiler via Static Binary and Linux Packages

In this final, concluding part on installing the Solidity compiler, we’ll be going through two more approaches, the static binary / precompiled Solidity Compiler installation, and Linux packages installation.

We will follow the outlined steps for these two fairly simple and quick approaches, and after that, make an overview of all the approaches we made in all four articles.

🌍 Related Tutorials:

Precompiled Solidity Compiler / Static Binary

In previous articles, we have shown how to set up our environment before being able to run the Solidity compiler.

However, here we’ll just download the compiler’s static binary, or in short, binary, and simply run it, without any additional prerequisites or preparations required.

The steps are:

First, downloading the file solc-static-linux and giving it an executable privilege:

$ cd ~ && wget https://github.com/ethereum/solidity/releases/download/v0.8.16/solc-static-linux
$ chmod +x ~/solc-static-linux

Second, running solc:

$ ~/solc-static-linux 1_Storage.sol -o output --abi --bin
Compiler run successful. Artifact(s) can be found in directory "output".

When checking our solidity_src directory, we’ll discover a new directory output, created by the Solidity compiler, containing both .abi and .bin files.

Info: to download the nightly build version instead of the latest stable release, replace the repository ppa:ethereum/ethereum in step 1. with ppa:ethereum/ethereum-dev.

Apart from simplicity, some other advantages of using the binaries are:

Possibility of getting static builds of past and current compiler versions for all supported platforms;
Using repositories for friendly access to binaries via Linux packages;
The binaries can be downloaded in the simplest form (no logging in, using locally installed versioning tools, e.g. git) from the online repository at https://github.com/ethereum/solidity/. The official documentation points to https://binaries.soliditylang.org, but it does not contain any downloadable content at the moment of writing this article;
Binaries are available to the tools running in the browser and can be directly loaded;
Newer versions of binaries do not require any form of installation or unpacking; there are some exceptions to this rule, but only in some older versions and for Windows environments.
Static binaries are kept in the online repository consistently and persistently;
The repository content is available in both HTTP and HTTPS protocols.

There are several warnings and recommendations we should take into account when retrieving the content (static binaries and accompanying content) repository, due to the build process reorganization:

Performance-wise, emscripten-wasm32/ is preferred to bin/; with version 0.6.2 the authors of Solidity compiler switched to WebAssembly builds with significantly improved performance.
Use emscripten-asmjs/ and emscripten-wasm32/ instead of bin/ and wasm/ to eliminate any ambiguity if the download is wasm or asm.js binary.
We should prefer list.json instead of list.js and list.txt, as list.json contains all the old information expanded with the new one.

Linux Packages Installation

Linux packages installation is a very simple procedure; we can do it in just a few steps:

Add the repository to our list of repositories:

$ sudo add-apt-repository ppa:ethereum/ethereum

Update the package list and install solc:

$ sudo apt update && sudo apt install -y solc

Now just run the Solidity compiler:

$ solc ~/solidity_src/1_Storage.sol --abi --bin -o ~/solidity_src/output
Compiler run successful. Artifact(s) can be found in directory "~/solidity_src/output".

Info: If we’d like to use the nightly build instead of the latest stable release, we should change the repository entry to ethereum/ethereum-dev.

The Compiler Installation Approaches Overview

Since the approach with static binaries seems so much easier and straightforward than the ones involving the installation of Node.js (for solc-js) or Docker (for solc), we might ask ourselves, what’s the deal? Why wouldn’t we just go with the static binary approach every time?

The answer would be, yes, we might take this simpler road — but simpler in a short term.

However, besides the obvious disadvantages of doing the extra work of installing Node.js or Docker when they are missing on our system, here are several more perspectives on using different approaches.

Browser-Based Development Environment with npm

For instance, solc-js can run inside a browser, which is an enormous advantage if we aim to make a browser-only development environment.

Just remember when we talked about Emscripten, LLVM, and WebAssembly; being able to compile and run in a browser is a very big deal!

Portable DApps with Docker

Likewise, Docker gives us an invaluable possibility of having portable applications, ready to use just by running the container (instantiating the image).

It takes away the hassle of having the application that runs nicely in one environment, but stubbornly defies to run in another environment.

Also, it enables us to experiment without breaking other dependencies because everything needed to run a Docker image is neatly containerized without any possibility of interference with other software dependencies.

Simple and Fast Linux Installation

Linux package installation is very simple and fast, but it deploys straight into the environment.

Depending on the environment we use, this might not be a welcomed approach.

If it’s an environment where a lot of experimenting is being done, where libraries are getting installed and removed, sooner or later our environment would become unstable or entirely unusable.
On the other hand, if it’s a dedicated, stable environment and we’re satisfied with having the latest stable version of the Solidity compiler via occasional upgrades, this is the way to go.

Full Control with Source Code Installation

Compiling the Solidity compiler from the source code in an unvirtualized environment is very similar in pros and cons to the Linux package installation, except for the two important features: version selection and compile-time/resources.

We surely have absolute control in selecting and compiling a specific version of the Solidity compiler source from the Git repository, which might be a needed and welcomed feature.

For instance, we can download a specific version and experiment with it, sensibly change the code, and have our own, unique version of the Solidity compiler.

On the other hand, compiling the Solidity source code (and some of its requirements, like z3) requires a lot more time and system resources.

However, having in mind that compiling the Solidity compiler is not something we do every day, if we find ourselves in a situation that demands this approach, we can follow it and have our own, home-compiled Solidity compiler.

Besides that, it’s reasonable to expect that the compilation result will be optimized for our machine in terms of performance, as opposed to prebuilt, readily available Docker images and static binaries.

👉 If you want to find out more ways to install the Solidity compiler, check out our full guide on the Finxter blog.

Conclusion

In this article, we made a final touch on our four-article journey through Solidity installation.

Concluding with the simplest methods of installation, i.e. pre-compiled Solidity compiler / static binary installation (a synonym) and the Linux packages installation, we made a wide overview of all the methods from all four articles.

First, we spied on how to smuggle and hide a static binary of the Solidity compiler. It is by far the simplest method, but it has its quirks.

Second, we shipped and waited patiently on our Linux packages to download. As you already know, I’m joking; the Linux package installation of the Solidity compiler finished blazing fast, and everything was set up for us just like that. We even managed to avoid the dreaded dependency hell!

In our grand finale, we laid out all the peculiarities of all the approaches: we dissected the best and worst in each of them, praised their strengths, and were kind to their weaknesses. But above all, we learned a lot and had fun doing all these experiments.

My Personal Preference for Solidity Compiler Installation

At the practical end of the article, if you’re asking me which approach to take for yourself, I’d recommend the following:

For simple experimenting and learning purposes, take the static binary Solidity compiler. It’ll serve you just fine.

For a more complex environment, where you’d gladly not mess anything up, go with the Docker image of the Solidity compiler. However, also learn about the other docker commands besides run, such as stop, start, ps -a, exec -it for interacting with the container and cleaning up afterward. Why? Because running a new container for each compilation can easily clutter your machine.

For a fast and usual approach to software management on Linux, go with the Linux package installation. It rarely messes up and it’s fixable when it does, but constrain yourself from too much experimenting.

For those quirky souls who like doing things the hard way and get their hands dirty (like yours truly), go with the installation of the Solidity Compiler via source compilation. In hope of your discouragement, I’m even making an exception and throwing in a picture of what my machine suffered through for that 1 h 45 min of giving birth to the Solidity compiler: