0.0 Using A Pre-compiled Binary
Pre-compiled binaries are available for recent releases. Just download the appropriate executable for your platform and put it on your $PATH. To uninstall, simply delete the executable. To upgrade from an older release, just overwrite the older binary with the newer one.
For details about how those binaries are built, see the Release Build How-To wiki page.
0.1 Executive Summary
Building and installing is very simple. Three steps:
- Download and unpack a source tarball or ZIP.
- ./configure; make
- Move the resulting "fossil" or "fossil.exe" executable to someplace on your $PATH.
1.0 Obtaining The Source Code
Fossil is self-hosting, so you can obtain a ZIP archive or tarball containing a snapshot of the latest version directly from Fossil's own fossil repository. Additionally, source archives of released versions of fossil are available from the downloads page. To obtain a development version of fossil, follow these steps:
- Point your web browser to https://fossil-scm.org/
Click on the Timeline link at the top of the page.
Select a version of Fossil you want to download. The latest version on the trunk branch is usually a good choice. Click on its link.
Finally, click on one of the "Zip Archive" or "Tarball" links, according to your preference. These links will build a ZIP archive or a gzip-compressed tarball of the complete source code and download it to your computer.
Aside: Is it really safe to use an unreleased development version of the Fossil source code?
Yes! Any check-in on the trunk branch of the Fossil self-hosting repository will work fine. (Dodgy code is always on a branch.) In the unlikely event that you pick a version with a serious bug, it still won't clobber your files. Fossil uses several self-checks prior to committing any repository change that prevent loss-of-work due to bugs.
The Fossil self-hosting repositories, especially the one at https://fossil-scm.org/home, usually run a version of trunk that is less than a week or two old. Look at the bottom left-hand corner of this screen (to the right of "This page was generated in...") to see exactly which version of Fossil is rendering this page. It is always safe to use whatever version of the Fossil code you find running on the main Fossil website.
2.0 Compiling
- Unpack the ZIP or tarball you downloaded then cd into the directory created.
(Optional, Debian-compatible Linux only) Make sure you have all the necessary tools and libraries at hand by running: sudo apt install tcl-dev tk libssl-dev zlib1g-dev.
(Optional, Unix only) Run ./configure to construct a makefile.
-
The build system for Fossil on Unix-like systems assumes that the
OpenSSL development and runtime files are available on your system,
because unprotected repositories are trivial to attack otherwise.
Indeed, some public Fossil repositories — including Fossil's own — today
run in an HTTPS-only mode, so that you can't even do an anonymous clone
from them without using the TLS features added to Fossil by OpenSSL. To
weaken that stance could allow a
man in the
middle attack, such as one that substitutes malicious code into your
Fossil repository clone.
You can force the Fossil build system to avoid searching for, building against, and linking to the OpenSSL library by passing --with-openssl=none to the configure script.
If you do not have the OpenSSL development libraries on your system, we recommend that you install them, typically via your OS's package manager. The Fossil build system goes to a lot of effort to seek these out wherever they may be found, so that is typically all you need to do.
For more advanced use cases, see the OpenSSL discussion in the "TLS and Fossil" document.
-
To build a statically linked binary, you can try adding the --static option, but it may well not work. If your platform of choice is affected by this, the simplest workaround we're aware of is to build a Fossil container, then extract the static executable from it.
-
To enable the native Tcl integration feature feature, add the --with-tcl=1 and --with-tcl-private-stubs=1 options.
-
Other configuration options can be seen by running ./configure --help
-
The build system for Fossil on Unix-like systems assumes that the
OpenSSL development and runtime files are available on your system,
because unprotected repositories are trivial to attack otherwise.
Indeed, some public Fossil repositories — including Fossil's own — today
run in an HTTPS-only mode, so that you can't even do an anonymous clone
from them without using the TLS features added to Fossil by OpenSSL. To
weaken that stance could allow a
man in the
middle attack, such as one that substitutes malicious code into your
Fossil repository clone.
Run "make" to build the "fossil" or "fossil.exe" executable. The details depend on your platform and compiler.
- Unix → the configure-generated Makefile should work on all Unix and Unix-like systems. Simply type "make".
Unix without running "configure" → if you prefer to avoid running configure, you can also use: make -f Makefile.classic. You may want to make minor edits to Makefile.classic to configure the build for your system.
MinGW / MinGW-w64 → The best-supported path is to build via the MinGW specific Makefile under a POSIX build of GNU make: "make -f win/Makefile.mingw".
MSVC → Use the MSVC makefile.
Cygwin → The same as other Unix-like systems. It is recommended to configure using: "configure --disable-internal-sqlite", making sure you have the "libsqlite3-devel" , "zlib-devel" and "openssl-devel" packages installed first.
There is limited support for building under MinGW's native Windows port of GNU Make instead by defining the USE_WINDOWS=1 variable, but it's better to build under MSYS, Cygwin, or WSL on Windows since this mode doesn't take care of cases such as the "openssl" target, which depends on sed. We've gone as far down this path as is practical short of breaking cross-compilation under Linux, macOS, and so forth, as we'd have to do to make everything work under cmd.exe.
Unless you're building under MSYS where commands like "gcc" give MinGW's GCC and not some other version, you will need to make minor edits to win/Makefile.mingw to configure the cross-compilation environment. It should suffice to switch to one of the predefined PREFIX values, causing the build to be done using "x86_64-w64-mingw32-gcc" for example, yielding a 64-bit native Windows binary.
To enable the native Tcl integration feature, use a command line like the following (all on one line):
make -f win/Makefile.mingw FOSSIL_ENABLE_TCL=1 FOSSIL_ENABLE_TCL_STUBS=1 FOSSIL_ENABLE_TCL_PRIVATE_STUBS=1
Alternatively, running ./configure under MSYS should give a suitable top-level Makefile. However, options passed to configure that are not applicable on Windows may cause the configuration or compilation to fail (e.g. fusefs, internal-sqlite, etc).
NB: Run the following nmake commands from a "x64 Native
Tools Command Prompt"; buildmsvc.bat is able to automatically load
the build tools (x64 by default, pass "x86" as the first argument to use the
x86 tools), so it can be called from a normal command prompt.
First, change to the "win/" subdirectory ("cd win"), then run
"nmake /f Makefile.msc".
Alternatively, the batch
file "win\buildmsvc.bat" may be used and it will attempt to
detect and use the latest installed version of MSVC.
To enable
the optional OpenSSL support,
first download the official
source code for OpenSSL and extract it to an appropriately named
"openssl" subdirectory within the local
compat directory then make sure that some recent
Perl binaries are installed locally,
and finally run one of the following commands:
nmake /f Makefile.msc FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin
buildmsvc.bat FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\binTo enable the optional native Tcl integration feature, run one of the following commands or add the "FOSSIL_ENABLE_TCL=1" argument to one of the other NMAKE command lines:
nmake /f Makefile.msc FOSSIL_ENABLE_TCL=1
buildmsvc.bat FOSSIL_ENABLE_TCL=1
3.0 Installing
- The finished binary is named "fossil" (or "fossil.exe" on Windows). Put this binary in a directory that is somewhere on your PATH environment variable. It does not matter where.
-
(Optional:) To uninstall, just delete the binary.
4.0 Additional Considerations
- If the makefiles that come with Fossil do not work for you, or for some other reason you want to know how to build Fossil manually, then refer to the Fossil Build Process document which describes in detail what the makefiles do behind the scenes.
-
The fossil executable is self-contained and stand-alone and usually requires no special libraries or other software to be installed. However, the "--tk" option to the diff command requires that Tcl/Tk be installed on the local machine. You can get Tcl/Tk from ActiveState.
-
To build on older Macs (circa 2002, MacOS 10.2) edit the Makefile generated by configure to add the following lines:
TCC += -DSQLITE_WITHOUT_ZONEMALLOC TCC += -D_BSD_SOURCE TCC += -DWITHOUT_ICONV TCC += -Dsocketlen_t=int TCC += -DSQLITE_MAX_MMAP_SIZE=0
5.0 Building a Docker Container
The information on building Fossil inside an OCI container is now in a separate document.
This includes the instructions on using the OCI container as an expedient intermediary for building a statically-linked Fossil binary on modern Linux platforms, which otherwise make this difficult.
6.0 Building on/for Android
6.1 Cross-compiling from Linux
The following instructions for building Fossil for Android via Linux, without requiring a rooted OS, are adapted from a forum post.
On the development machine, from the fossil source tree:
export CC=$NDK_PATH/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi21-clang
./configure --with-openssl=none
make
On the Android device, enable the USB debugging option from
Developer menu in Device Options. Connect the device to the development
system with USB. If it's configured and connected properly,
the device should show up in the output of adb devices:
sudo adb devices
Copy the resulting fossil binary onto the device...
sudo adb push fossil /data/local/tmp
And run it from an adb shell:
sudo adb shell
> cd /data/local/tmp
# Fossil requires a HOME directory to work with:
> export HOME=$PWD
> export PATH=$PWD:$PATH
> fossil version
This is fossil version 2.11 [e5653a4ceb] 2020-03-26 18:54:02 UTC
The output might, or might not, include warnings such as:
WARNING: linker: ./fossil: unused DT entry: type 0x6ffffef5 arg 0x1464
WARNING: linker: ./fossil: unused DT entry: type 0x6ffffffe arg 0x1ba8
WARNING: linker: ./fossil: unused DT entry: type 0x6fffffff arg 0x2
The source of such warnings is not 100% certain. Some information about these (reportedly harmless) warnings can be found on this StackOverflow post.
7.0 Building for Fuzz Testing
This feature is primarily intended for fossil's developers and may change at any time. It is only known to work on Linux systems and has been seen to work on x86/64 and ARM.
Fossil has builtin support for processing specific features using libfuzzer. The features which can be tested this way are found in the help text for the test-fuzz command.
Fuzzing requires:
- Customizing the build of fossil a small bit.
- The clang C compiler.
- libfuzzer. On Ubuntu-derived systems, it can be installed with apt install libfuzzer-XYZ, where XYZ is a version number (several versions may be available on any given system)
First, modify the top-level Makefile.in:
- Extend the TCCFLAGS variable with: -fsanitize=fuzzer -DFOSSIL_FUZZ (and see src/fuzz.c for more options).
- Rename APPNAME from fossil to fossil-fuzz.
Then rebuild:
$ make clean $ ./configure CC=/path/to/clang $ make
If clang is your default compiler, the CC configure option is not required.
The resulting fossil-fuzz binary differs from the standard one primarily in that it runs the test-fuzz command by default. It needs to be told what to fuzz and needs to be given a directory of input files to seed the fuzzer with:
$ mkdir cases # Copy input files into ./cases. e.g. when fuzzing the markdown # processor, copy any to-be-tested .md files into that directory. # Then start the fuzzer: $ ./fossil-fuzz --fuzztype markdown cases
As it works, it writes its mutated test files into the test-input directory, each one named in the form of a hash. When it finds a problem it will produce a stack trace for the offending code, will output the name of the file which triggered the crash (named cases/SOME_HASH) and may, depending on the nature of the problem, produce a file named crash-SOMETHING. In theory the crash file can be fed directly back into the fuzzer to reproduce the problem:
$ ./fossil-fuzz --fuzztype markdown crash-SOMETHING
But whether or not it will genuinely crash may depend on static app-level state which might not trigger the crash when running an individual test.
For a detailed information about the fuzzer's flags and features, see:
- https://llvm.org/docs/LibFuzzer.html
- https://github.com/google/fuzzing/blob/master/tutorial/libFuzzerTutorial.md
Flags for the fuzzer can be passed directly to fossil, e.g. -jobs=4 to start four fuzzer jobs in parallel, but doing so may cause the fuzzer to strip the --fuzztype flag, leading to it testing the wrong thing. When passing on fuzzer-specific flags along with --fuzztype, be sure to check your system's process list to ensure that your --fuzztype flag is there.
8.0 Building WebAssembly Components
Fossil uses one component built as WebAssembly a.k.a. WASM. Because compiling WASM code requires non-trivial client-side tooling, the repository includes compiled copies of these pieces. Most Fossil hackers should never need to concern themselves with the WASM parts, but this section describes how to for those who want or need to do so.
The bits described in this section are necessary when updating extsrc/pikchr.c from the upstream source, or the fossil binary will use a different version of pikchr than /pikchrshow does (as the latter runs the WASM build of pikchr).
These instructions have only ever been tested on Linux systems. They "should" work on any Unix-like system supported by Emscripten. The fossil makefiles for Windows builds do not include any of the WASM-related components (patches to add that would be welcomed, of course).
The first step is to configure the tree with support for Emscripten. This requires that the system has the Emscripten SDK (a.k.a. emsdk) installed, as documented at:
https://emscripten.org/docs/getting_started/downloads.html
For instructions on keeping the SDK up to date, see:
https://emscripten.org/docs/tools_reference/emsdk.html
After installing the SDK, configure the fossil tree with emsdk support:
$ ./configure --with-emsdk=/path/to/emsdk \
--and-other-options...
If the --with-emsdk flag is not provided, the configure script will check for the environment variable EMSDK, which is one of the standard variables the SDK environment uses. If that variable is found, its value will implicitly be used in place of the missing --with-emsdk flag. Thus, if the emsdk_env.sh script is sourced into the shell before running the configure script, the SDK will be detected even without the config flag.
The configure script installs some makefile variables which tell the build where to find the SDK and it generates a script named tools/emcc.sh (from the template file /tools/emcc.sh.in), which is a wrapper around the Emscripten C compiler (emcc). The wrapper script uses the configure-time state to attempt to set up the various environment variables which are required by emcc and will fail if it cannot do so. Once it's set up the environment, it passes on all of its arguments to emcc.
The WASM-related build parts are set up such that none of them should ever trigger implicitly (e.g. via dependencies resolution) in a normal build cycle. They are instead explicitly built as described below.
From the top of the source tree, all WASM-related components can be built with:
$ make wasmAs of this writing, those parts include:
- extsrc/pikchr.wasm is a WASM-compiled form of extsrc/pikchr.c.
- extsrc/pikchr.js is JS/WASM glue code generated by Emscripten to give JS code access to the API exported by the WASM file.
When a new version of extsrc/pikchr.c is installed, the files pikchr.{js,wasm} will need to be recompiled to account for that. Running make wasm will, if the build is set up for the emsdk, recompile those:
$ make wasm
./tools/emcc.sh -o extsrc/pikchr.js ...
$ ls -la extsrc/pikchr.{js,wasm}
-rw-rw-r-- 1 stephan stephan 17263 Jun 8 03:59 extsrc/pikchr.js
-rw-rw-r-- 1 stephan stephan 97578 Jun 8 03:59 extsrc/pikchr.wasm
After that succeeds, we need to run the normal build so that those generated files can be compiled in to the fossil binary, accessible via the /builtin page:
$ makeBefore checking in those newly-built files, they need to be tested by running the /pikchrshow page. If that page loads, the compilation process fundamentally worked (a load failure will be made obvious to the viewer). If it fails to load then the browser's dev tools console likely provides at least a small hint (and sometimes a useful hint) about the nature of the problem. Don't check those files in until /pikchrshow runs, though!
Should pikchr's C interface ever change, pikchr-worker.js will need to be updated to accommodate it, but such modification is typically trivial.
8.1 Solutions other than Emscripten?
Emscripten is not the only option for building C as WASM, but it provides a complete toolchain which eliminates many other steps which must otherwise be accounted for on a per-project basis. Despite its convenience, it behooves us to explore other build options for the sake of portability and avoiding what amounts to vendor lock-in.
For later refererence, here are articles specifically covering building WASM projects without using Emscripten: