# Gambit Scheme: Build, Install, and First Use

> Gambit is a portable Scheme implementation built around the gsi interpreter, gsc compiler, and a broad set of SRFI libraries. Its source build is straightforward, but module downloads and platform tuning require deliberate attention.

**gambit/gambit** — Gambit is an efficient implementation of the Scheme programming language.

- Repository: https://github.com/gambit/gambit
- Website: http://gambitscheme.org/
- Stars: 1,446 · Forks: 206
- Language: Scheme
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/gambit-gambit

## Gambit Scheme's Compiled Runtime and Interpreter

Gambit addresses programmers who need a full Scheme environment rather than a limited Scheme-like scripting format. The README describes it as a complete, portable implementation of Scheme, and its build explicitly produces a runtime library along with `gsi` and `gsc`. The repository layout reinforces that interpretation. Separate `gsi/`, `gsc/`, `lib/`, and `include/` directories separate the interpreter, compiler, libraries, and headers, while `tests/`, `doc/`, `bench/`, and `examples/` provide distinct paths for verification, documentation, benchmarks, and sample programs.

This design is relevant to command-line utilities, executable Scheme applications, and code that needs access to native facilities. The README also describes SRFI 22 for running Scheme scripts on Unix and includes an `examples/` tree with native integration examples such as `Xlib-simple/`, `pthread/`, `ring/`, `tcltk/`, and `web-server/`. Based on that directory layout, Gambit is not confined to expression evaluation. It includes materials for scripts, native interfaces, concurrent programs, and web-oriented examples.

The standard library position is unusually broad for a compact review. The README marks features such as numeric vectors, basic string ports, records, multithreading, error reporting, random bits, boxes, command-line handling, and bitwise operations as built in. It also lists libraries for hash tables, streams, format strings, generators, intervals, generalized arrays, sorting, and integer division. SRFI 64 is the notable exception in the displayed list: its implementation is labeled incomplete. Applications that require complete SRFI 64 behavior therefore need separate verification rather than relying on its presence in the list.

## Building Gambit from the Master Branch

The README gives a source-build path for Windows, Linux, and macOS. This is the clearest first use for a developer who wants the repository version rather than an unspecified packaged release. No GitHub releases are listed, so the repository does not provide a release-based installation path there.

Clone the repository, enter its directory, configure the build, compile it, and install it as shown here:

```bash
git clone https://github.com/gambit/gambit.git
cd gambit
./configure
make
make check
make doc
sudo make install
```

The README describes `make` as building the runtime library, `gsi`, and `gsc`. It marks `make check` as optional but recommended, while `make doc` builds the documentation. The final command requires installation privileges because it uses `sudo`. A build completion message or installed executable would be platform-dependent, so the reliable checkpoints are the successful completion of each command and the presence of the installed tools.

The README also says that if an error or `Ctrl-C` interrupts the first invocation of `make`, the build should be restarted from the `git clone` step to avoid possible corruption in files generated during bootstrap. That is a concrete operational constraint. Gambit's initial build is therefore not presented as a safely resumable workflow after every interruption. The more detailed `INSTALL.txt` file is the project's stated source for platform-specific installation guidance.

## Running Gambit's First Remote Scheme Module

After installation, the README provides a direct module execution example that exercises `gsi` beyond an ordinary source file. It invokes a public Git repository as a Scheme module:

```bash
gsi github.com/gambit/hello/demo
```

This is a useful first check if network access and the repository hosting the module are available. The README says such modules can be hosted in a public Git repository and run directly through `gsi`. It also gives a second example that restricts executable module sources to a GitHub host:

```bash
gsi -:whitelist=github.com/feeley github.com/feeley/bonjour
```

The `-:whitelist=github.com/feeley` argument makes the execution boundary visible. Rather than accepting the second URL as an isolated manual invocation, the command associates allowed module retrieval with the specified GitHub account path. This is relevant when source retrieval itself is part of the trust decision.

The README does not state that the linked third-party module remains available, nor does it define expected terminal output from either example. Availability and behavior therefore need verification at the point of use. The examples establish a supported execution pattern, not a guarantee about external repository uptime. The module system is useful for distributing Scheme code as public Git repositories, but it also means that a reproducible deployment must account for module source availability.

## Tuning Gambit for a Single Target Host

For a machine dedicated to running Gambit programs, the README recommends a different `configure` invocation. This is not merely a shorthand for the default build. It requests a single-host build, enables the host processor instruction set, and permits a dynamic C library:

```bash
./configure --enable-single-host --enable-march=native --enable-dynamic-clib
```

The README calls this configuration recommended for best performance. However, `--enable-march=native` creates a deployment boundary that needs attention: the README does not state that binaries built this way are portable to older CPUs. The intended audience is therefore a system where Gambit will run on the build host, rather than an artifact copied indiscriminately across a mixed machine fleet.

`--enable-single-host` and `--enable-dynamic-clib` should also be treated as build-policy choices, not defaults. The README gives the flags but does not explain their implementation details or trade-offs. An engineer preparing binary artifacts needs a separate build configuration or must avoid the native tuning option. For the default route, plain `./configure` remains the least specific choice described by the README.

## Dockerfile Build Versus Local Source Installation

The repository's `Dockerfile` offers a concrete alternative to installing Gambit directly on the host. Instead of a developer running the build steps interactively, the container image starts from `gcc:9.3.0`, copies the repository into `/gambit_install`, and runs a larger build sequence. It then links the built `gsi` and `gsc` executables into `/bin` and changes the working directory to `/workdir`.

The Dockerfile expresses this sequence as follows:

```dockerfile
FROM gcc:9.3.0
WORKDIR gambit_install
COPY . .
RUN make clean && ./configure --enable-single-host && make -j$(nproc) && make check && make modules && make doc && make install
RUN ln -s /gambit_install/gsi/gsi /bin/gsi && ln -s /gambit_install/gsc/gsc /bin/gsc
WORKDIR /workdir
```

The two approaches differ in control. The README path leaves compilation flags and installed paths under the developer's control. The Dockerfile centralizes them in an image definition, runs `make modules` as part of its build, and exposes the two commands through container-local symbolic links. It also ties the build to the compiler image version recorded as `gcc:9.3.0`. This gives repeatable instructions, but the Dockerfile does not document image maintenance, runtime dependencies beyond its setup, or a release policy.

## Gambit Maintenance, Upgrades, and License Boundaries

The repository is not archived, and its last push was on 2026-10-12. That is recent enough to indicate that repository work has continued, but it does not substitute for a release history. There are no GitHub releases in the repository record, so upgrade planning cannot rely on versioned release artifacts listed there. The README points to the Gambit web page for the latest official release and related documentation.

An upgrade can involve source-control movement, a fresh bootstrap build, self-tests, documentation generation, and installation. The warning about restarting from `git clone` after an interrupted first `make` adds cost to failure recovery, because generated bootstrap files may need to be discarded. Build and system administration effort should therefore be included in the adoption decision, especially on multiple platforms.

The repository contains `LGPL.txt` and `LICENSE-2.0.txt`, while the project metadata does not identify the license conclusively. The presence of both files does not establish that every file, example, or external module is covered by the same terms. This article does not provide legal interpretation. Review those files and any notices associated with linked modules before distributing binaries or incorporating Gambit code. The remote `github.com/feeley/bonjour` example also requires a separate license review because its source is outside the Gambit repository.

## Conclusion

Gambit is appropriate for Scheme developers who can build native source and want gsi, gsc, SRFI support, and local integration with C libraries. It is a poor fit for users who need a documented prebuilt installation path or cannot provide a working compiler and build environment. Before adoption, verify the licensing files that apply to the code you use, exercise `make check` on each target platform, and confirm that remote modules and native flags match your deployment policy. For a conventional source build with the gsi and gsc tools, Gambit is a practical Scheme implementation, subject to those checks.

## FAQ

### How do I install Gambit Scheme from source?

The README directs users to clone the repository, run `./configure`, compile with `make`, optionally run `make check` and `make doc`, and finish with `sudo make install`. It also points to `INSTALL.txt` for detailed instructions.

### What is the difference between gsi and gsc in Gambit Scheme?

The build description says that `make` builds the runtime library, `gsi`, and `gsc`. It also identifies `gsi` as the command used to execute public Git-hosted Scheme modules in the README examples.

### Does Gambit Scheme have official release packages?

The README says the latest official release and related documents can be obtained from the Gambit web page. The repository record lists no GitHub releases, so no GitHub release artifact is identified here.

## Sources

- [gambit/gambit on GitHub](https://github.com/gambit/gambit)
- [Issues](https://github.com/gambit/gambit/issues)
- [Project website](http://gambitscheme.org/)
- [README](https://github.com/gambit/gambit/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gambit-gambit