Installing the Solidity Compiler — Solidity 0.8.33-develop documentation
Versioning
Solidity versions follow Semantic Versioning. In addition, patch-level releases with major release 0 (i.e. 0.x.y) will not contain breaking changes. That means code that compiles with version 0.x.y can be expected to compile with 0.x.z where z > y.
In addition to releases, we provide prereleases and nightly development builds to make it easy for developers to try out upcoming features and provide early feedback. Note that such builds contain bleeding-edge code from the development branch and are not guaranteed to be of the same quality as full releases. Despite our best efforts, they might contain undocumented and/or broken changes that will not become a part of an actual release. They are not meant for production use.
When deploying contracts, you should use the latest released version of Solidity. This is because breaking changes, as well as new features and bug fixes are introduced regularly. We currently use a 0.x version number to indicate this fast pace of change.
Remix
We recommend Remix for small contracts and for quickly learning Solidity.
Access Remix online, you do not need to install anything. If you want to use it without connection to the Internet, go to https://github.com/ethereum/remix-live/tree/gh-pages#readme and follow the instructions on that page. Remix is also a convenient option for testing nightly builds without installing multiple Solidity versions.
Further options on this page detail installing command-line Solidity compiler software on your computer. Choose a command-line compiler if you are working on a larger contract or if you require more compilation options.
npm / Node.js
Use npm for a convenient and portable way to install solcjs, a Solidity compiler. The solcjs program has fewer features than the ways to access the compiler described further down this page. The Using the Commandline Compiler documentation assumes you are using the full-featured compiler, solc. The usage of solcjs is documented inside its own repository.
Note: The solc-js project is derived from the C++ solc by using Emscripten, which means that both use the same compiler source code. solc-js can be used in JavaScript projects directly (such as Remix). Please refer to the solc-js repository for instructions.
npm install --global solcDocker
Docker images of Solidity builds are available using the solc image from the argotorg organization on ghcr.io. Use the stable tag for the latest released version, and nightly for potentially unstable changes in the develop branch.
The Docker image runs the compiler executable so that you can pass all compiler arguments to it. For example, the command below pulls the stable version of the solc image (if you do not have it already), and runs it in a new container, passing the --help argument.
To use the Docker image to compile Solidity files on the host machine, mount a local folder for input and output, and specify the contract to compile. For example:
You can also use the standard JSON interface (which is recommended when using the compiler with tooling). When using this interface, it is not necessary to mount any directories as long as the JSON input is self-contained (i.e. it does not refer to any external files that would have to be loaded by the import callback).
Linux Packages
Binary packages of Solidity are available at solidity/releases.
Ubuntu packages for versions up to 0.8.30 are available in the ethereum/ethereum PPA. However, we have discontinued this distribution method and future versions will not be added there.
Furthermore, some Linux distributions provide their own packages. These packages are not directly maintained by us but usually kept up-to-date by the respective package maintainers.
For example, Arch Linux has packages for the latest development version as AUR packages: solidity and solidity-bin.
Please be aware that AUR packages are user-produced content and unofficial packages. Exercise caution when using them.
There is also a snap package, however, it is currently unmaintained. It is installable in all the supported Linux distros. To install the latest stable version of solc:
If you want to help testing the latest development version of Solidity with the most recent changes, please use the following:
The solc snap uses strict confinement. This is the most secure mode for snap packages but it comes with limitations, like accessing only the files in your /home and /media directories. For more information, go to Demystifying Snap Confinement.
macOS Packages
We distribute the Solidity compiler through Homebrew as a build-from-source version. Pre-built bottles are currently not supported.
To install the most recent 0.4.x / 0.5.x version of Solidity you can also use brew install solidity@4 and brew install solidity@5, respectively.
If you need a specific version of Solidity you can install a Homebrew formula directly from Github.
View solidity.rb commits on GitHub.
Copy the commit hash of the version you want and check it out on your machine.
Install it using brew:
Static Binaries
We maintain a repository containing static builds of past and current compiler versions for all supported platforms at solc-bin. This is also the location where you can find the nightly builds.
The repository is not only a quick and easy way for end users to get binaries ready to be used out-of-the-box but it is also meant to be friendly to third-party tools:
The content is mirrored to https://binaries.soliditylang.org where it can be easily downloaded over HTTPS without any authentication, rate limiting or the need to use git.
Content is served with correct
Content-Typeheaders and lenient CORS configuration so that it can be directly loaded by tools running in the browser.Binaries do not require installation or unpacking (exception for older Windows builds bundled with necessary DLLs).
We strive for a high level of backward-compatibility. Files, once added, are not removed or moved without providing a symlink/redirect at the old location. They are also never modified in place and should always match the original checksum. The only exception would be broken or unusable files with the potential to cause more harm than good if left as is.
Files are served over both HTTP and HTTPS. As long as you obtain the file list in a secure way (via git, HTTPS, IPFS or just have it cached locally) and verify hashes of the binaries after downloading them, you do not have to use HTTPS for the binaries themselves.
The same binaries are in most cases available on the Solidity release page on GitHub. The difference is that we do not generally update old releases on the GitHub release page. This means that we do not rename them if the naming convention changes and we do not add builds for platforms that were not supported at the time of release. This only happens in solc-bin.
The solc-bin repository contains several top-level directories, each representing a single platform. Each one includes a list.json file listing the available binaries. For example in emscripten-wasm32/list.json you will find the following information about version 0.7.4:
This means that:
You can find the binary in the same directory under the name solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js. Note that the file might be a symlink, and you will need to resolve it yourself if you are not using git to download it or your file system does not support symlinks.
The binary is also mirrored at https://binaries.soliditylang.org/emscripten-wasm32/solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js. In this case git is not necessary and symlinks are resolved transparently, either by serving a copy of the file or returning a HTTP redirect.
The file is also available on IPFS at QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS. Please, be aware that the order of items in the
urlsarray is not predetermined or guaranteed and users should not rely on it.You can verify the integrity of the binary by comparing its keccak256 hash to
0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3. The hash can be computed on the command-line usingkeccak256sumutility provided by sha3sum or keccak256() function from ethereumjs-util in JavaScript.You can also verify the integrity of the binary by comparing its sha256 hash to
0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2.
Due to the strong backwards compatibility requirement the repository contains some legacy elements but you should avoid using them when writing new tools:
Use
emscripten-wasm32/(with a fallback toemscripten-asmjs/) instead ofbin/if you want the best performance. Until version 0.6.1 we only provided asm.js binaries. Starting with 0.6.2 we switched to WebAssembly builds with much better performance. We have rebuilt the older versions for wasm but the original asm.js files remain inbin/. The new ones had to be placed in a separate directory to avoid name clashes.Use
emscripten-asmjs/andemscripten-wasm32/instead ofbin/andwasm/directories if you want to be sure whether you are downloading a wasm or an asm.js binary.Use
list.jsoninstead oflist.jsandlist.txt. The JSON list format contains all the information from the old ones and more.
The solc-bin.ethereum.org domain is no longer supported. Going forward, we recommend any tools which are still using it as the source of Solidity binaries to switch to binaries.soliditylang.org.
The binaries are also available at https://argotorg.github.io/solc-bin/ but this page stopped being updated just after the release of version 0.7.2, will not receive any new releases or nightly builds for any platform and does not serve the new directory structure, including non-emscripten builds.
If you are using it, please switch to https://binaries.soliditylang.org, which is a drop-in replacement.
Building from Source
Prerequisites - All Operating Systems
The following are dependencies for all builds of Solidity:
Minimum Compiler Versions
The following C++ compilers and their minimum versions can build the Solidity codebase:
Prerequisites - macOS
For macOS builds, ensure that you have the latest version of Xcode installed. This contains the Clang C++ compiler, the Xcode IDE and other Apple development tools that are required for building C++ applications on OS X. If you are installing Xcode for the first time, or have just installed a new version then you will need to agree to the license before you can do command-line builds:
Our OS X build script uses the Homebrew package manager for installing external dependencies. Here’s how to uninstall Homebrew, if you ever want to start again from scratch.
Prerequisites - Windows
You need to install the following dependencies for Windows builds of Solidity:
C++ compiler
Visual Studio 2019 (Optional)
C++ compiler and dev environment.
Boost (version 1.77+)
C++ libraries.
If you already have one IDE and only need the compiler and libraries, you could install Visual Studio 2019 Build Tools.
Visual Studio 2019 provides both IDE and necessary compiler and libraries. So if you have not got an IDE and prefer to develop Solidity, Visual Studio 2019 may be a choice for you to get everything setup easily.
Here is the list of components that should be installed in Visual Studio 2019 Build Tools or Visual Studio 2019:
Visual Studio C++ core features
VC++ 2019 v141 toolset (x86,x64)
Windows Universal CRT SDK
Windows 8.1 SDK
C++/CLI support
We have a helper script which you can use to install all required external dependencies:
This will install boost and cmake to the deps subdirectory.
Clone the Repository
To clone the source code, execute the following command:
If you want to help develop Solidity, you should fork Solidity and add your personal fork as a second remote:
Command-Line Build
Be sure to install External Dependencies (see above) before build.
Solidity project uses CMake to configure the build. You might want to install ccache to speed up repeated builds. CMake will pick it up automatically. Building Solidity is quite similar on Linux, macOS and other Unices:
or even easier on Linux and macOS, you can run:
BSD builds should work, but are untested by the Solidity team.
And for Windows:
In case you want to use the version of boost installed by scripts\install_deps.ps1, you will additionally need to pass -DBoost_ROOT="deps/boost" -DBoost_INCLUDE_DIR="deps/boost/include" and -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded as arguments to the call to cmake.
This should result in the creation of solidity.sln in that build directory. Double-clicking on that file should result in Visual Studio firing up. We suggest building Release configuration, but all others work.
Alternatively, you can build for Windows on the command-line, like so:
CMake Options
If you are interested what CMake options are available run cmake .. -LH.
SMT Solvers
Solidity can optionally use SMT solvers, namely z3, cvc5 and Eldarica, but their presence is checked only at runtime, they are not needed for the build to succeed.
The Version String in Detail
The Solidity version string contains four parts:
the version number
pre-release tag, usually set to
develop.YYYY.MM.DD,pre.Nornightly.YYYY.MM.DDcommit in the format of
commit.GITHASHplatform, which has an arbitrary number of items, containing details about the platform and compiler
If there are local modifications, the commit will be postfixed with .mod.
These parts are combined as required by SemVer, where the Solidity pre-release tag equals to the SemVer pre-release and the Solidity commit and platform combined make up the SemVer build metadata.
Examples:
release:
0.4.8+commit.60cc1668.Emscripten.clangpre-release:
0.4.9-pre.3+commit.fb60450bc.Emscripten.clangnightly build:
0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang
Important Information About Versioning
After a release is made, the patch version level is bumped, because we assume that only patch level changes follow. When changes are merged, the version should be bumped according to SemVer and the severity of the change. Finally, a release is always made with the version of the current build, but without the prerelease specifier.
This behavior works well with the version pragma.