Dependencies does not follow --target?


On windows, in a cmd configured with:

call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86

I’m trying to build a 32bits DLL by calling:

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

but many dependencies fail to build:

error: linking with `C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\link.exe` failed: exit code: 1112
  = note: msvcrt.lib(chkstk.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

and I can noticed in the lib path from the huge command line just before the error:


when I’m expecting i686-pc-windows-msvc instead.

Am I missing something or did I bumped into some cargo bug?

> cargo --version
cargo 1.29.0 (524a578d7 2018-08-05)

If I configured my console with:

call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_amd64

then dependencies build fine but my final DLL fails to link because of using 64bits linker.

Build scripts and all their build dependencies have to be built for the host so they can run directly. Technically, an i686 target binary could still run on an x86_64 host, but that’s not true of cross compiling in general.

Proc-macro plugins, for custom derive, also have to match the host because they’re are loaded by the compiler, in process. There’s no way around this unless you just use the i686 compiler to begin with.

But you can do that! rustup install stable-i686-pc-windows-msvc should give you that native i686 compiler.


Wow, I’ve search online on how to compile for 32 bits target and I’ve never stumble upon a native 32 bits toolchain Oo How did I missed it :tired_face:

Thanks a lot!

Is there a way to specify a default toolchain in the .cargo/config for a particular crate? Or do I need to do cargo +stable-i686-pc-windows-msvc build ?

If you want a solution just for your machine, use a directory override. If you want something you can check into source control, use a toolchain file.

That said, I wonder if you really need to be using vcvarsall.bat at all. I thought rustc already had logic to auto-discover these paths on the fly, so maybe if you left that out it could just find the right linker on its own, even for the “cross” compiled target from x86_64 to i686. I’m not super familiar with the Windows side though.

1 Like

I need this before opening VSCode otherwise the RLS can fail :slight_smile:

What sort of RLS failures do you encounter when you don’t use vcvarsall.bat?

On the project, it does not build, pop an error without any helpful information and nothing work after that, no completion, no navigation, no type tooltip. I had to launch VScode from a batch file which call vcvarall.bat before

Correction, I’ve just tested again without vcvarsall.bat and it works now.