7

I decided to update my boost libraries from 1.61 to 1.63, and in the project that I updated to use the new files, I'm getting some new error messages I wasn't getting before:

error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAAEBVerror_category@12@XZ)
error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAAEBVerror_category@12@XZ)

Since my 1.63 libraries are being compiled using Visual Studio 2017, my first assumption is that I've made a mistake compiling the boost libraries, so here are the total steps I'm taking from a clean unzip of the boost files:

  1. Start Menu→Visual Studio 2017 RC→Developer Command Prompt
  2. I change directory until I'm in the high-level boost_1_63_0 folder.
  3. I run bootstrap.bat
  4. I open project-config.jam for editing
  5. I change using msvc ; to using msvc : 14.1 : E:\Program Files\Microsoft Visual Studio\VC\Tools\MSVC\14.10.24911\bin\HostX64\x64\;
  6. I open boost/config/auto_link.hpp for editing
  7. I make an edit to this file (code listed below after the list)
  8. In the open command prompt, I execute the command b2 architecture=x86 address-model=64 link=static threading=multi runtime-link=shared --build-type=complete stage --stagedir=stage/x64 -a
  9. It completes with the following message at the end (listed below after the list)
  10. I attempt to use these libraries with my code, using #define BOOST_LIB_DIAGNOSTIC to track that the correct files are being used (they are).
  11. I attempt to compile my project that uses boost.asio, and get the two unresolved external symbol errors listed above.

Does anyone know where my mistake is? These errors do not occur if I use the boost 1.61 libraries compiled using Visual Studio 2015 in Visual Studio 2017 RC.

auto_link.hpp (old):

# elif defined (BOOST_MSVC)

     // vc14:
#  define BOOST_LIB_TOOLSET "vc140"

auto_link.hpp (new):

# elif defined (BOOST_MSVC) && (BOOST_MSVC < 1910)

     // vc14:
#  define BOOST_LIB_TOOLSET "vc140"

# elif defined (BOOST_MSVC)

     // vc15:
#  define BOOST_LIB_TOOLSET "vc141"

Message at the end of the boost compilation process:

...failed updating 6 targets...
...skipped 4 targets...
...updated 904 targets...

Libraries shown by use of #define BOOST_LIB_DIAGNOSTIC:

1>Linking to lib file: libboost_system-vc141-mt-1_63.lib
1>Linking to lib file: libboost_date_time-vc141-mt-1_63.lib
1>Linking to lib file: libboost_regex-vc141-mt-1_63.lib

Let me know if there's any other diagnostic information needed. I tried commenting out various uses of the boost.asio library, but only removing the header entirely eliminated these issues (which, of course, made the boost components unusable).

Xirema
  • 19,889
  • 4
  • 32
  • 68
  • I'm not sure if this has anything to do with the errors, but the path to the `msvc` toolset looks weird: it's in `Program Files`, not `Program Files (x86)`, as if you're on 32-bit Windows, but you're requesting the 64-bit native compiler (`HostX64`). Also, the `Developer Command Prompt` shortcut corresponds to `HostX86\x86` (32-bit compiler building 32-bit code). To get the 64-bit compiler building 64-bit code you should use the `x64 Native Tools Command Prompt` shortcut. Maybe this is confusing the build scripts somehow? – bogdan Feb 15 '17 at 17:24
  • Just on the offchance, you are not using the header files of the old version of boost while linking against the new one are you? You may have to update the preprocessor path to the matching new boost? – Vality Feb 15 '17 at 17:24
  • @bogdan When I install stuff on my `E:/` drive, I usually force it installed into the `Program Files` folder, regardless of whether it wants to use the (x86) suffix or not. And since I did that for both VC2015 and VC2107, I don't think it's an issue. I am going to look into using the x64 Native Tools Command Prompt though, and see if it works or not. – Xirema Feb 15 '17 at 17:32
  • Also, on my side I used the complete path to `cl.exe`, not just the directory name. Otherwise, I did mostly the same thing, but I named the toolset `15.0`, as there's some reference to `vc15` in some boost build file (I have no idea if this has any relevance). Also note that `--build-type=complete` is somewhat inconsistent with specifying those other properties on the command line, as those are actually selecting a subset of build variations. I would use just `b2 address-model=64 link=static threading=multi runtime-link=shared variant=debug,release`. – bogdan Feb 15 '17 at 17:33
  • 1
    @bogdan Using the correct command prompt (`x64 Native Tools Command Prompt`) fixed the problem. If you want to post that as an answer, I'll accept it and award you the bounty. – Xirema Feb 15 '17 at 19:03

1 Answers1

5

This seems to be similar as LNK 2019 error using Boost::asio as you have the same errors.

I just installed VS2017RC and boost 1.63. Then I used this description: Build boost with msvc 14.1 ( VS2017 RC) . Note: your line

using msvc : 14.1 : E:\Program Files\Microsoft Visual Studio\VC\Tools\MSVC\14.10.24911\bin\HostX64\x64\;

should probably include the "cl.exe" and quotes.

using msvc : 14.1 : "E:\Program Files\Microsoft Visual Studio\VC\Tools\MSVC\14.10.24911\bin\HostX64\x64\cl.exe";

...They should implement a progress bar or such ;) Guess what:

...failed updating 6 targets...
...skipped 4 targets...
...updated 1214 targets...

So look at the error message:

msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\debug\address-model-64\link-static\threading-multi\asm\make_x86_64_ms_pe_masm.obj
'ml64' is not recognized as an internal or external command, operable program or batch file.
ml64 -nologo -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE /Zi /Zd /W3  -Fo "bin.v2\libs\context\build\msvc-14.1\debug\address-model-64\link-static\threading-multi\asm\make_x86_64_ms_pe_masm.obj" "libs\context\src\asm\make_x86_64_ms_pe_masm.asm"
...failed msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\debug\address-model-64\link-static\threading-multi\asm\make_x86_64_ms_pe_masm.obj...

Missing 64-bit dependencies... So, like KindDragon says in the second link:

Run "Developer Command Prompt for VS 2017 RC" from Windows Start Menu to boostrap from a shell configured using the x86 vcvars or x64 vcvars.

It is necessary to configure the shell using the 64-bit compiler variables.

cd "\Program Files (x86)\Microsoft Visual Studio 14.0\VC"
vcvarsall amd64

..alternatively you could start the x64 native environment from the Start menu: -> Visual Studio 201x -> Visual Studio Tools -> Windows Desktop Command Prompts -> VS201x x64 Native Tools Command Prompt

And then build again.

...failed updating 2 targets...
...skipped 2 targets...
...updated 6 targets...

With error message fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'. So a rebuild is required.

b2 --clean-all
etc...

...You get the point. But it seems I read now in the comments that Bogdan has also mentioned this. Well, Kinddragon in Build boost with msvc 14.1 ( VS2017 RC) was actually first ;)

Community
  • 1
  • 1
JHBonarius
  • 10,824
  • 3
  • 22
  • 41
  • This answer shows sufficient effort and saves me from having to write one, so I think there's no problem with it getting the bounty. For the benefit of other readers, I think it would be great if it made the conclusion more prominent - make it easier for someone to understand what caused the problem. – bogdan Feb 17 '17 at 09:16