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?

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](https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=vs-2019#developer_command_file_locations). — Kevin, Jun 14 '19 at 18:50
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](https://www.boost.org/doc/libs/1_62_0/tools/build/tutorial.html#feature_reference) — Kevin, Jun 14 '19 at 19:12
@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 — BigBoy1337, Jun 14 '19 at 20:18
Someone from Boost should take a look at this! It's embarrassing — user997112, Jun 21 '20 at 01:24

score 7 · Answer 1 · answered Jun 15 '19 at 07:10

7

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.

answered Jun 15 '19 at 07:10

kenba

4,303
1
23
40

hmm after building with that, I still get the same cmake complaint about 32-bit boost libraries being found instead of 64 bit – BigBoy1337 Jun 17 '19 at 18:22
`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. – kenba Jun 18 '19 at 07:06
1

thanks for the note about boost false default address-model message. – sailfish009 Sep 04 '19 at 05:46
This is true, output is false, confirmed. – metablaster May 07 '20 at 23:59

score 0 · Answer 2 · answered Sep 29 '20 at 00:20

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.

JoseOrtiz3 · Answer 3 · 2020-08-03T18:19:06.070

-3

My guide has detailed instructions that may be useful for how to build 64-bit boost on Windows 10 in Visual Studio 2019 with python and mpi support. I wrote the notes in case I ever needed to do it again.

I thought it might have something to do with leaving out --

b2 --address-model=64

But someone has told me that is not correct.

edited Aug 03 '20 at 18:19

answered Jun 26 '19 at 04:09

JoseOrtiz3

1,785
17
28

2

For me, it is not "--address-model" but "address-model". Answers like this cost many people much time – IceFire Aug 02 '20 at 18:07
@IceFire Sorry I threw you off, not sure when `--` is necessary or breaking. I never build boost anymore, and simply get the precompiled binaries instead. – JoseOrtiz3 Aug 03 '20 at 18:20

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

3 Answers3

Linked