How to build 64-bit boost for visual studio on windows using the address-model flag?

Question

I am trying to build boost on the x64 terminal for Visual Studio using these instructions: https://www.boost.org/doc/libs/1_62_0/more/getting_started/windows.html#get-boost

I do:

boostrap

then

.\b2 address-model=64

but it always says:

C:\boost_1_70_0>.\b2 address-model=64
Performing configuration checks

    - default address-model    : 32-bit
    - default architecture     : x86

Building the Boost C++ Libraries.

...

and then goes on to build 32 bit versions of everything. I know this because when I try and use boost for things like CMake it complains that its 32 bit:

C:\src\SimpleAmqpClient\simpleamqpclient-build>cmake -DBOOST_ROOT=C:\boost_1_70_0 -DBOOST_LIBRARYDIR=C:\boost_1_70_0\stage\lib ..
-- Found Boost 1.70.0 at C:/Program Files/boost/lib/cmake/Boost-1.70.0
--   Requested configuration: QUIET REQUIRED COMPONENTS chrono;system
-- Found boost_headers 1.70.0 at C:/Program Files/boost/lib/cmake/boost_headers-1.70.0
-- Found boost_chrono 1.70.0 at C:/Program Files/boost/lib/cmake/boost_chrono-1.70.0
-- No suitable boost_chrono variant has been identified!
--   libboost_chrono-mgw82-mt-d-x32-1_70.a (32 bit, need 64)
--   libboost_chrono-mgw82-mt-x32-1_70.a (32 bit, need 64)
CMake Error at C:/Program Files/boost/lib/cmake/Boost-1.70.0/BoostConfig.cmake:95 (find_package):
  Found package configuration file:

    C:/Program Files/boost/lib/cmake/boost_chrono-1.70.0/boost_chrono-config.cmake

  but it set boost_chrono_FOUND to FALSE so package "boost_chrono" is
  considered to be NOT FOUND.  Reason given by package:

  No suitable build variant has been found.

Call Stack (most recent call first):
  C:/Program Files/boost/lib/cmake/Boost-1.70.0/BoostConfig.cmake:124 (boost_find_dependency)
  C:/Program Files/CMake/share/cmake-3.15/Modules/FindBoost.cmake:273 (find_package)
  CMakeLists.txt:35 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!
See also "C:/src/SimpleAmqpClient/simpleamqpclient-build/CMakeFiles/CMakeOutput.log".

So yeah, how can I build 64-bit?

Godoy

Are you sure it is using the 64-bit terminal? You may also have to enable a 64-bit build environment by running something like this vcvars64.bat. See here. – Finale

You can also try build from a regular cmd command line: .\b2 toolset=msvc-15.0 address-model=64 --stagedir=stage link=shared You can specify the toolset there, as well as whether to build static or shared libraries with the link option. Full reference – Finale

@squareskittles where does that vcvars64.bat file live? Im having trouble running it. Also, .\b2 toolset=msvc-15.0 address-model=64 --stagedir=stage link=shared seems to also build for 32 bit - same output as in my original question – Godoy

What version of Visual Studio are you using? – Finale

Visual Studio 2019 – Godoy

Someone from Boost should take a look at this! It's embarrassing – Coherent

Answer 1

See the answer I gave here: How to build Boost 1.64 in 64 bits?
If you want to specify the toolset explicitly then Visual Studio 2019 is toolset=msvc-14.2

Note: ensure that you build it from a Visual Studio tools Command Prompt
and ignore the - default address-model : 32-bit output on the console, it builds 64 bit binaries.

Tanning

hmm after building with that, I still get the same cmake complaint about 32-bit boost libraries being found instead of 64 bit – Godoy

Cmake is finding boost at C:/Program Files/boost/ not at C:\boost_1_70_0. You have multiple boost libraries on your machine and it's finding the wrong one. – Tanning

thanks for the note about boost false default address-model message. – Appraisal

This is true, output is false, confirmed. – Latchstring

Answer 2

I just ran into this problem. Even though I specified address-model=64 on the command line and the 32-bit tools weren't in my PATH and the 64-bit tools were, Jam used the 32-bit tools. And it didn't even know it was doing it: it put x64 in the names of the 32-bit libraries it created using the 32-bit tools that it had gone out of its way to find and invoke. I love "smart" build systems.

I don't know why it happened, but I worked around it by editing bin.v2\standalone\msvc\msvc-{version}\address-model-64\architecture-x86\msvc-setup.bat and moving ...\bin\Hostx64\x64 before ...\bin\HostX86\x86 in the SET PATH=... line.

As mentioned in another answer, it still reports "default address-model: 32-bit" even when it's correctly building 64-bit binaries.

Mcauliffe