-2

When I try to compile the sample ssl client program taken from the asio website, using multithreaded debug, multibyte characterset configuration I get a linker error:

asioclient2010.obj : error LNK2019: unresolved external symbol "void __cdecl boost::asio::async_connect,class boost::_bi::bind_t,class boost::_bi::list2,struct boost::arg<1> > > >(class boost::asio::basic_socket &,class boost::asio::ip::basic_resolver_iterator,class boost::_bi::bind_t,class boost::_bi::list2,struct boost::arg<1> > > const &,void *)" (??$async_connect@Vtcp@ip@asio@boost@@V?$basic_resolver_iterator@Vtcp@ip@asio@boost@@@234@V?$bind_t@XV?$mf1@XVclient@@ABVerror_code@system@boost@@@_mfi@boost@@V?$list2@V?$value@PAVclient@@@_bi@boost@@U?$arg@$00@3@@_bi@3@@_bi@4@@asio@boost@@YAXAAV?$basic_socket@Vtcp@ip@asio@boost@@@01@V?$basic_resolver_iterator@Vtcp@ip@asio@boost@@@ip@01@ABV?$bind_t@XV?$mf1@XVclient@@ABVerror_code@system@boost@@@_mfi@boost@@V?$list2@V?$value@PAVclient@@@_bi@boost@@U?$arg@$00@3@@_bi@3@@_bi@1@PAX@Z) referenced in function "public: __thiscall client::client(class boost::asio::io_context &,class boost::asio::ssl::context &,class boost::asio::ip::basic_resolver_iterator)" (??0client@@QAE@AAVio_context@asio@boost@@AAVcontext@ssl@23@V?$basic_resolver_iterator@Vtcp@ip@asio@boost@@@ip@23@@Z)

If I build it as a VS2017 project it links fine. I'm guessing its a problem with the version of boost?

What is the latest version of boost that is compatible with VS2010?

http://think-async.com/Asio/boost_asio_1_10_6/doc/html/boost_asio/example/cpp03/ssl/client.cpp

deltanine
  • 1,166
  • 1
  • 13
  • 25
  • Possible duplicate of [What is an undefined reference/unresolved external symbol error and how do I fix it?](https://stackoverflow.com/questions/12573816/what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix) – Ken White Jan 25 '18 at 00:55
  • this is not a duplicate. – deltanine Jan 29 '18 at 03:42

2 Answers2

1

What is the latest version of boost that is compatible with VS2010?

The latest version of boost (1.66.0) is compatible.

Aside from that you will have to specify at least the library directory of your boost version in your Linker -> Additional Library Directories settings.

For SSL you will ALSO have to specify the library path and the corresponding library files in your linker / command line. The current version of boost is compatible with the newer SSL versions (1.1.0#) too so this is not a problem either.

You can check the dependencies inside the DEPENDENCY_VERSIONS.txt when downloading the binaries.

Microsoft Visual Studio 2010 - msvc-10.0 - Service Pack 1

SSL Additional Library Directories and command-line for the linker are here as a sample. These are depending on your installation & version - here I am using OpenSSL 1.1.0f 64-bit.

SSL Additional Library Directories:

C:\OpenSSL-Win64\lib

Command-line:

"libssl.lib" "libcrypto.lib"

Blacktempel
  • 3,935
  • 3
  • 29
  • 53
  • Thanks for the answer. I am using openssl 1.1.0f 32 bit too. – deltanine Jan 29 '18 at 00:09
  • When I build it as a VS2017 project it works fine. The server code from the asio examples also works fine built under VS2010. http://think-async.com/Asio/boost_asio_1_10_6/doc/html/boost_asio/example/cpp03/ssl/server.cpp It seems to have a problem with this line of code failing to link: boost::asio::async_connect(socket_.lowest_layer(), endpoint_iterator, boost::bind(&client::handle_connect, this, boost::asio::placeholders::error)); – deltanine Jan 29 '18 at 00:17
1

It turns out the version of async_connect which takes a single iterator fails to link on VS2010.

boost::asio::async_connect(socket_.lowest_layer(), 
     endpoint_iterator,
     boost::bind(&client::handle_connect, 
                 this,
                 boost::asio::placeholders::error));

According to the documentation:

This overload assumes that a default constructed object of type Iterator represents the end of the sequence. This is a valid assumption for iterator types such as boost::asio::ip::tcp::resolver::iterator.

Calling the second overload of async_connect and explicitly passing in an end iterator solves the issue:

    boost::asio::ip::tcp::resolver::iterator dummy_end_iterator;
    boost::asio::async_connect(socket_.lowest_layer(),
        endpoint_iterator, dummy_end_iterator,
        boost::bind(&client::handle_connect, 
                    this,
                    boost::asio::placeholders::error));

http://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/reference/async_connect.html

deltanine
  • 1,166
  • 1
  • 13
  • 25