.. index:: ! installing
Solidity versions follow semantic versioning and in addition to releases, nightly development builds are also made available. The nightly builds are not guaranteed to be working and despite best efforts they might contain undocumented and/or broken changes. We recommend using the latest release. Package installers below will use the latest release.
If you just want to try Solidity for small contracts, you can try Remix which does not need any installation. If you want to use it without connection to the Internet, you can go to https://github.com/ethereum/browser-solidity/tree/gh-pages and download the .ZIP file as explained on that page.
This is probably the most portable and most convenient way to install Solidity locally.
A platform-independent JavaScript library is provided by compiling the C++ source into JavaScript using Emscripten. It can be used in projects directly (such as Remix). Please refer to the solc-js repository for instructions.
It also contains a commandline tool called solcjs, which can be installed via npm:
npm install -g solc
Note
The comandline options of solcjs are not compatible with solc and tools (such as geth) expecting the behaviour of solc will not work with solcjs.
We provide up to date docker builds for the compiler. The stable
repository contains released versions while the nightly
repository contains potentially unstable changes in the develop branch.
docker run ethereum/solc:stable solc --version
Currenty, the docker image only contains the compiler executable, so you have to do some additional work to link in the source and output directories.
Binary packages of Solidity available at solidity/releases.
We also have PPAs for Ubuntu. For the latest stable version.
sudo add-apt-repository ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install solc
If you want to use the cutting edge developer version:
sudo add-apt-repository ppa:ethereum/ethereum
sudo add-apt-repository ppa:ethereum/ethereum-dev
sudo apt-get update
sudo apt-get install solc
Arch Linux also has packages, albeit limited to the latest development version:
pacman -S solidity-git
Homebrew is missing pre-built bottles at the time of writing, following a Jenkins to TravisCI migration, but Homebrew should still work just fine as a means to build-from-source. We will re-add the pre-built bottles soon.
brew update
brew upgrade
brew tap ethereum/ethereum
brew install solidity
brew linkapps solidity
If you need a specific version of Solidity you can install a Homebrew formula directly from Github.
View solidity.rb commits on Github.
Follow the history links until you have a raw file link of a
specific commit of solidity.rb
.
Install it using brew
:
brew unlink solidity
# Install 0.4.8
brew install https://raw.githubusercontent.com/ethereum/homebrew-ethereum/77cce03da9f289e5a3ffe579840d3c5dc0a62717/solidity.rb
To clone the source code, execute the following command:
git clone --recursive https://github.com/ethereum/solidity.git
cd solidity
If you want to help developing Solidity, you should fork Solidity and add your personal fork as a second remote:
cd solidity
git remote add personal [email protected]:[username]/solidity.git
Solidity has git submodules. Ensure they are properly loaded:
git submodule update --init --recursive
For macOS, ensure that you have the latest version of Xcode installed. This contains the Clang C++ compiler, the Xcode IDE and other Apple development tools which 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:
sudo xcodebuild -license accept
Our OS X builds require you to install the Homebrew package manager for installing external dependencies. Here's how to uninstall Homebrew, if you ever want to start again from scratch.
You will need to install the following dependencies for Windows builds of Solidity:
Software | Notes |
---|---|
Git for Windows | Command-line tool for retrieving source from Github. |
CMake | Cross-platform build file generator. |
Visual Studio 2015 | C++ compiler and dev environment. |
We now have a "one button" script which installs all required external dependencies on macOS, Windows and on numerous Linux distros. This used to be a multi-step manual process, but is now a one-liner:
./scripts/install_deps.sh
Or, on Windows:
scripts\install_deps.bat
Building Solidity is quite similar on Linux, macOS and other Unices:
mkdir build
cd build
cmake .. && make
or even easier:
#note: this will install binaries solc and soltest at usr/local/bin
./scripts/build.sh
And even for Windows:
mkdir build
cd build
cmake -G "Visual Studio 14 2015 Win64" ..
This latter set of instructions 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 RelWithDebugInfo configuration, but all others work.
Alternatively, you can build for Windows on the command-line, like so:
cmake --build . --config RelWithDebInfo
The Solidity version string contains four parts:
- the version number
- pre-release tag, usually set to
develop.YYYY.MM.DD
ornightly.YYYY.MM.DD
- commit in the format of
commit.GITHASH
- platform has 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.
A relase example: 0.4.8+commit.60cc1668.Emscripten.clang
.
A pre-release example: 0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang
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 nightly build, but without the prerelease
specifier.
Example:
- the 0.4.0 release is made
- nightly build has a version of 0.4.1 from now on
- non-breaking changes are introduced - no change in version
- a breaking change is introduced - version is bumped to 0.5.0
- the 0.5.0 release is made
This behaviour works well with the :ref:`version pragma <version_pragma>`.