Rust i686 Windows Cross Compile: Prepare for Rust 1.100

Rust's compiler team announced on October 2 that Rust 1.100 will stop shipping host tools for the two 32-bit Windows targets, i686-pc-windows-msvc and i686-pc-windows-gnu. The standard library will remain available, so developers can still produce 32-bit Windows programs; the workflow is changing from running Rust directly on a 32-bit Windows machine to cross-compiling from a supported host. Rust 1.100 is scheduled for November 12, 2026, which gives existing projects time to move their build machines and continuous integration jobs.

What changes for i686 Windows projects in Rust 1.100

The key distinction is between a host tool and a target. A host tool is software that runs on the development machine, such as the Rust compiler and Cargo, while a target describes the platform for which your application is being built. Rust 1.100 will keep the prebuilt standard library for 32-bit Windows, but the Rust compiler and other host tools will no longer be distributed for a 32-bit Windows host. The i686-pc-windows-msvc target remains Tier 1 without host tools, while i686-pc-windows-gnu moves to Tier 2 without host tools.

This does not mean Rust can no longer create 32-bit Windows executables. A 64-bit Windows development machine can still install the i686 target and ask Cargo to compile the project for it. The difference is where rustc and Cargo run: they run on the 64-bit host while producing a 32-bit Windows binary. That is the cross-compilation model the Rust team now recommends for these targets.

Check your current Rust host before changing anything

Start by finding out whether your development machine is actually using a 32-bit Rust host. Run these commands in a terminal:

rustc --version --verbose rustup show

Look for the host: value in the compiler information and the active toolchain in the rustup show output. A host such as i686-pc-windows-msvc means the compiler itself is running as a 32-bit Windows toolchain. A host such as x86_64-pc-windows-msvc means the compiler runs on 64-bit Windows, which is the setup you want for future i686 builds.

The Rust project's current platform documentation distinguishes host-tool support from standard-library support for exactly this reason. A target can remain a valid compilation target without being suitable as the machine on which the Rust toolchain itself runs.

Move the development environment to 64-bit Windows

If the machine running your Rust toolchain is still 32-bit Windows, move the project to a 64-bit Windows development machine before Rust 1.100 becomes stable. The Rust team says that after Rust 1.100 it will no longer be possible to install Rust toolchains on 32-bit Windows hosts. This is a host change, not a requirement to abandon 32-bit application output.

On the new machine, install Rust with rustup and verify that the host is 64-bit:

rustup update stable rustc --version --verbose

For Windows development, the MSVC Rust target uses Microsoft's native compiler and libraries. The Rust documentation recommends the MSVC ABI for most Windows work, and Microsoft documents the C++ build tools as a prerequisite for Rust development on Windows.

Add the 32-bit Windows target to the 64-bit toolchain

Once the host is 64-bit, install the i686 target instead of installing an i686 host toolchain. For an MSVC-based application, use:

rustup target add i686-pc-windows-msvc

The command adds the 32-bit Windows standard library to your existing Rust toolchain. You do not need to change the host architecture just because the output architecture is different. Rust's documentation explicitly describes architectural cross-compilation from one Windows host to another Windows architecture as supported by the MSVC toolchain when the appropriate Visual Studio components are installed.

If your project deliberately uses the GNU Windows target instead, install its target separately:

rustup target add i686-pc-windows-gnu

The two targets are not interchangeable. The MSVC target uses Microsoft's native Windows toolchain, while the GNU target uses the MinGW-based toolchain. The Rust project has already moved i686-pc-windows-gnu to Tier 2, and Rust 1.100 will remove host-tool support from it as well.

Install the Windows components needed for MSVC builds

If your project uses i686-pc-windows-msvc, make sure the Visual Studio installation includes the C++ desktop workload and the x86/x64 MSVC build tools. Microsoft's current Build Tools component list identifies the latest x86/x64 MSVC tools as a supported component, while its Rust setup documentation lists the Desktop development with C++ workload as the Windows prerequisite.

You do not need a separate 32-bit Windows machine just to produce the 32-bit executable. The host compiler remains 64-bit, while the linker and libraries used for the target produce the 32-bit PE/COFF output. This separation is the central change to make in a project that currently depends on an i686 Windows host.

Build the project explicitly for i686 Windows

With the target installed, a normal Cargo project can be compiled with the --target option. Create or open your project and run:

cargo build --release --target i686-pc-windows-msvc

Cargo's target option tells the build system which platform the output should target rather than using the host platform. If the command completes successfully, the release binary is placed under the target-specific build directory, normally following the pattern target/i686-pc-windows-msvc/release/. Cargo documents build.target as the configuration equivalent of repeatedly supplying a target on the command line.

For a quick test project, the workflow can be reduced to:

cargo new i686-test cd i686-test rustup target add i686-pc-windows-msvc cargo build --release --target i686-pc-windows-msvc

The important result is not merely a successful Cargo command. The compiler is running on the 64-bit host, while the produced executable is intended for 32-bit x86 Windows. That is the workflow that remains after Rust 1.100 removes the i686 host tools.

Check the binary instead of trusting the folder name

A successful build tells you Cargo completed its work, but when supporting multiple architectures it is worth verifying the resulting executable. Windows PE/COFF binaries contain architecture information that can be inspected with Microsoft's development tools or other PE inspection utilities. The Rust platform documentation confirms that the Windows MSVC targets produce PE/COFF binaries, with the i686 target following the 32-bit x86 Windows ABI.

You can also keep the target explicit in your build scripts and CI configuration rather than relying on whichever host happens to run the job. That makes an architecture mistake visible in the command itself. A build that says cargo build --release --target i686-pc-windows-msvc is considerably easier to audit than a generic release build whose output architecture depends on the machine running it.

Make the target permanent in Cargo when appropriate

If a project always produces its primary release artifact for 32-bit Windows, Cargo can store the target in its configuration instead of requiring the command-line flag every time. Create a .cargo/config.toml file and add:

[build] target = "i686-pc-windows-msvc"

After that, an ordinary release build uses the configured target:

cargo build --release

This setting is useful for a project dedicated to one target, but it can become inconvenient for a library or application that also needs native 64-bit builds. Cargo supports target-specific configuration, so a multi-platform project can instead keep the target explicit in its release scripts or CI jobs.

Update CI before Rust 1.100 reaches stable

Continuous integration is the part most likely to expose this change unexpectedly. If a workflow currently provisions a 32-bit Windows runner and installs an i686 Rust toolchain on that runner, that setup will no longer work once Rust 1.100 lands. The Rust team's recommendation is to use a still-supported host, such as 64-bit Windows, and cross-compile the i686 target from there.

A Windows CI job can therefore follow the same basic sequence as a developer workstation:

rustup update stable rustup target add i686-pc-windows-msvc cargo build --release --target i686-pc-windows-msvc

Do not change the target to x86_64-pc-windows-msvc merely to make the CI runner easier to configure if your users still require a 32-bit executable. The whole point of this migration is that the host can change to 64-bit while the application target remains i686.

Watch native dependencies when cross-compiling

A Rust-only project is usually the simplest case because the Rust standard library for the i686 target is supplied by the project. The situation becomes more complicated when a crate builds or links native C or C++ code. The Rust documentation specifically calls out C-code cross-compilation for Windows MSVC targets and requires the appropriate Visual Studio components for the target architecture.

This means you should audit dependencies that use build scripts, foreign-function interfaces, or native libraries before migrating the machine. A Rust crate may compile correctly for i686 until its build script tries to compile a native dependency using the wrong architecture. The safest approach is to build the complete release artifact on the new 64-bit host rather than testing only a small Rust-only example.

Understand what still works after Rust 1.100

The Rust 1.100 change is narrower than a complete removal of 32-bit Windows support. The standard library remains available for both i686 Windows targets, and i686-pc-windows-msvc keeps Tier 1 status without host tools. The GNU target retains its standard-library builds as well, but moves to Tier 2 without host tools.

The practical dividing line is therefore the development machine. Running Rust directly on 32-bit Windows is the workflow being retired. Building a 32-bit Windows application from a supported 64-bit Windows host remains the intended workflow. Rust's release schedule currently places Rust 1.100 on November 12, so projects that still depend on 32-bit Windows development machines have a concrete date to test against.

If your project already builds i686 Windows binaries from a 64-bit host, the announcement requires much less work: verify that the target is explicitly installed, run a complete release build, and check the CI environment. If your compiler itself runs on 32-bit Windows, the migration is more fundamental, because the machine hosting the toolchain has to change before Rust 1.100 removes those host tools.