0

I am building a 64bit program on Windows and need to link to a Boost library.

I am using other 64bit libraries successfully.

When I built boost I specified exactly that I need 64bit libraries using the command

`.\b2 address-model=64'

And it built the library I need:

`libboost-serialization-vc120-mt-s-x64_1_77.lib'

This should be a 64bit library as its name implies.

However when I try to compile my program I get the linking error:

Description: `error LINK1112: module machine type 'X86' conflicts with target machine type 'x64'

File: `libboost-serialization-vc120-mt-s-x64_1_77.lib'

What's going on - it is a 64bit library why is it saying that it conflicts with machine type 'x64' and what can I do about it?

user3353819
  • 911
  • 2
  • 8
  • 21
  • Are you compiling your own project in 32-bit configuration? – user3389943 Sep 24 '21 at 14:19
  • No, 64bit, confirmed (I am linking to other 64 bit libraries that built before trying to link to this one), the machine type 'x64' is *my* program. I found a question that refers to the same phenomenon: https://stackoverflow.com/questions/56603575/how-to-build-64-bit-boost-for-visual-studio-on-windows-using-the-address-model-f/56608193 it seems the problem is the boost build system *saying* it is 64bit, but it is actually 32 bit. But I can't see a solid answer or one that I can replicate... – user3353819 Sep 24 '21 at 14:22
  • You could use dumpbin (available in your VS 2013 binaries) to verify that the library is 64 bit like in this answer: [https://superuser.com/a/1658663/76204](https://superuser.com/a/1658663/76204) – drescherjm Sep 24 '21 at 14:45

1 Answers1

1

Ok, I "figured out" how to get round this.

Basically, what I thought was happening was happening. Despite specifying a 64bit build and those libraries getting the name appropriate to a 64bit build, they were being built using the 32bit tool-chain.

To anyone from Boost who happens to see this - this is a REALLY bad experience and should be fixed

To get it to build the libraries correctly I had to run a .bat script hidden away in the MSVC program files to set the environment to 64bit before the usual boost procedure.

There are a variety of these scripts for different purposes as detailed here, although infuriatingly it doesn't specify where to find them.

After hunting around for them I found the file I needed vcvarsx86_amd64.bat (for complicated reasons I'm using an old version of MSVC which only comes in a 32bit flavor but can cross-compile 64bit code).

For me this was found in

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat

Note: for any of this to work this all has to be done inside a developer command prompt which for me was located at

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts

Once in the that command prompt the proper library files were then built by typing

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat
bootstrap vc12
b2 address-model=64

Then it linked as expected.

Disclaimer: Unnecessary opinion - feel free to edit this away...

Coming from *nix environments, all of this seems terrible. Boost is essential to c++ development, but just getting it to build with MSVC is so incredibly contrived, opaque, and just... broken. Almost like it is designed to make it difficult. How do you put up with it?

user3353819
  • 911
  • 2
  • 8
  • 21
  • I my build trees I create script that calls the correct vcvars batch file for the compiler and 32/64 and put that in the root folder of each tree. Inside that I build boost and use CMake with the environment setup for the compiler I use. – drescherjm Sep 24 '21 at 15:18
  • That is very sensible in hindsight, but the issue (that makes me grumble) is that it isn't contained, well documented, or even error checked. There are MSVC environment settings that need to be set to get the build right that can't be done in the *industry standard* CMake file and colossal boost build system. They simply aren't an option in boost build and no-where does it mention them! Worse no errors are thrown if the tool chain doesn't match the user specified build. It (seems to me) to be objectively *bad* as a system - not that you can't do clever things to get round it, like you have. – user3353819 Sep 24 '21 at 15:23
  • Yeah the rantiness is a bit.. subjective. Yes, it sucks that MSVC has - for decades - continued shipping a plethora of these "developer variable batch files".It's hardly something that Boost can fix, except for them reiterating this bit of MSVC documentation. – sehe Sep 24 '21 at 17:25
  • No reference to this at all here: https://www.boost.org/doc/libs/1_77_0/more/getting_started/windows.html – user3353819 Sep 25 '21 at 04:22