OpenSSL Dependencies - Windows and OSX

[Bioxydyn Dev]

Hi,

I have successfully built cpp-netlib (v0.10.1) on both Windows using VS
2013 and OS X using clang. My application that uses cpp-netlib also builds
on both platforms. However, I encoutnered some unresolved symbols on
Windows that I didn't on OS X and wondered if anyone could enlighten me as
to the cause.

I create a client as follows:

client::request request(url);
client httpClient;
client::response response = httpClient.post(request, "some message");

On OS X this builds fine but on Windows I had to include ssleay32MTd.lib
and libeay32MTd.lib as additional link dependencies to resolve a load of
external symbols. I've included some of them below.

Can anyone tell me why this might be the case?

Error 1 error LNK2019: unresolved external symbol
_CRYPTO_cleanup_all_ex_data referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::~do_init(void)"
(??***@openssl_init_base@***@ssl@***@boost@@***@XZ)
cppnetlib-client-connections.lib(client.obj)
Error 2 error LNK2019: unresolved external symbol _CRYPTO_num_locks
referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::do_init(void)"
(??***@openssl_init_base@***@ssl@***@boost@@***@XZ)
cppnetlib-client-connections.lib(client.obj)
Error 3 error LNK2019: unresolved external symbol
_CRYPTO_set_locking_callback referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::do_init(void)"
(??***@openssl_init_base@***@ssl@***@boost@@***@XZ)
cppnetlib-client-connections.lib(client.obj)
Error 4 error LNK2019: unresolved external symbol _CRYPTO_set_id_callback
referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::do_init(void)"
(??***@openssl_init_base@***@ssl@***@boost@@***@XZ)
cppnetlib-client-connections.lib(client.obj)
Error 5 error LNK2019: unresolved external symbol _BIO_ctrl_pending
referenced in function "private: enum
boost::asio::ssl::detail::engine::want __thiscall
boost::asio::ssl::detail::engine::perform(int (__thiscall
boost::asio::ssl::detail::engine::*)(void *,unsigned int),void *,unsigned
int,class boost::system::error_code &,unsigned int *)"
(?***@engine@***@ssl@***@boost@@AAE?***@12345@***@AEHPAXI@***@system@***@PAI@Z)
cppnetlib-client-connections.lib(client.obj)

[Dean Michael Berris]

This is because Boost.Asio depends on OpenSSL, and all the
dependencies that OpenSSL has. If you're building in OS X and linking
OpenSSL, you're bringing in all the dependencies of OpenSSL too
(-lcrypt).

Hi,
I have successfully built cpp-netlib (v0.10.1) on both Windows using VS 2013
and OS X using clang. My application that uses cpp-netlib also builds on
both platforms. However, I encoutnered some unresolved symbols on Windows
that I didn't on OS X and wondered if anyone could enlighten me as to the
cause.
client::request request(url);
client httpClient;
client::response response = httpClient.post(request, "some message");
On OS X this builds fine but on Windows I had to include ssleay32MTd.lib and
libeay32MTd.lib as additional link dependencies to resolve a load of
external symbols. I've included some of them below.
Can anyone tell me why this might be the case?
Error 1 error LNK2019: unresolved external symbol
_CRYPTO_cleanup_all_ex_data referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::~do_init(void)"
cppnetlib-client-connections.lib(client.obj)
Error 2 error LNK2019: unresolved external symbol _CRYPTO_num_locks
referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::do_init(void)"
cppnetlib-client-connections.lib(client.obj)
Error 3 error LNK2019: unresolved external symbol
_CRYPTO_set_locking_callback referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::do_init(void)"
cppnetlib-client-connections.lib(client.obj)
Error 4 error LNK2019: unresolved external symbol _CRYPTO_set_id_callback
referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::do_init(void)"
cppnetlib-client-connections.lib(client.obj)
Error 5 error LNK2019: unresolved external symbol _BIO_ctrl_pending
referenced in function "private: enum boost::asio::ssl::detail::engine::want
__thiscall boost::asio::ssl::detail::engine::perform(int (__thiscall
boost::asio::ssl::detail::engine::*)(void *,unsigned int),void *,unsigned
int,class boost::system::error_code &,unsigned int *)"
cppnetlib-client-connections.lib(client.obj)
--
You received this message because you are subscribed to the Google Groups
"The C++ Network Library" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/cpp-netlib.
For more options, visit https://groups.google.com/groups/opt_out.

[Bioxydyn Dev]

Hi Dean,

Thanks for your response.

Post by Dean Michael Berris
This is because Boost.Asio depends on OpenSSL, and all the
dependencies that OpenSSL has. If you're building in OS X and linking
OpenSSL, you're bringing in all the dependencies of OpenSSL too
(-lcrypt).

I understand that Boost.Asio depends on OpenSSL. I also understand that
cpp-netlib depends on Boost.Asio. As my application depends on cpp-netlib,
then it also depends ultimately on OpenSSL.

However, my question was why when I build my application on OS X, I don't
need to link in additional OpenSSL Libraries but on Windows I do (i.e.
ssleay32MTd.lib and libeay32MTd.lib). It is enough on OS X to link in
cppnetlib-uri l& cppnetlib-client-connections but on Windows it isn't.

[Dean Michael Berris]

Post by Bioxydyn Dev
Hi Dean,
Thanks for your response.

Post by Dean Michael Berris
This is because Boost.Asio depends on OpenSSL, and all the
dependencies that OpenSSL has. If you're building in OS X and linking
OpenSSL, you're bringing in all the dependencies of OpenSSL too
(-lcrypt).

I understand that Boost.Asio depends on OpenSSL. I also understand that
cpp-netlib depends on Boost.Asio. As my application depends on cpp-netlib,
then it also depends ultimately on OpenSSL.
However, my question was why when I build my application on OS X, I don't
need to link in additional OpenSSL Libraries but on Windows I do (i.e.
ssleay32MTd.lib and libeay32MTd.lib). It is enough on OS X to link in
cppnetlib-uri l& cppnetlib-client-connections but on Windows it isn't.

This depends on how CMake finds the libraries. I think in 0.11.0-rc2
this has been "fixed" unless it hasn't been for MSVC. Generally the
default I think has switched from static linkage (which made things
simple) to dynamic linkage which is how you're getting these issues.

What you need to remember here is that the versions of OpenSSL vary,
and that I don't test on Windows because I don't have access to that
platform (nor will I have access to that platform in the near future).
All I can do is guess that in Windows, you ought to really add those
as dependencies to things that need OpenSSL. I suspect that if these
DLLs are found in a common search path for libraries, that they would
be found properly without you having to do anything special. If you
have OpenSSL installed in a non-centralized path, then this would
cause you precisely this kind of trouble.

[Bioxydyn Dev]

Post by Bioxydyn Dev

Post by Bioxydyn Dev
Hi Dean,
Thanks for your response.

Post by Dean Michael Berris
This is because Boost.Asio depends on OpenSSL, and all the
dependencies that OpenSSL has. If you're building in OS X and linking
OpenSSL, you're bringing in all the dependencies of OpenSSL too
(-lcrypt).

I understand that Boost.Asio depends on OpenSSL. I also understand that
cpp-netlib depends on Boost.Asio. As my application depends on

cpp-netlib,

Post by Bioxydyn Dev
then it also depends ultimately on OpenSSL.
However, my question was why when I build my application on OS X, I

don't

Post by Bioxydyn Dev
need to link in additional OpenSSL Libraries but on Windows I do (i.e.
ssleay32MTd.lib and libeay32MTd.lib). It is enough on OS X to link in
cppnetlib-uri l& cppnetlib-client-connections but on Windows it isn't.

This depends on how CMake finds the libraries. I think in 0.11.0-rc2
this has been "fixed" unless it hasn't been for MSVC. Generally the
default I think has switched from static linkage (which made things
simple) to dynamic linkage which is how you're getting these issues.

Where is the default specified? I'm building static libs on both OS X and
Windows. The following are in my CMakeCache.txt for both platforms:

//Dependencies for target
cppnetlib-client-connections_LIB_DEPENDS:STATIC=

//Dependencies for target
cppnetlib-server-parsers_LIB_DEPENDS:STATIC=

//Dependencies for target
cppnetlib-uri_LIB_DEPENDS:STATIC=

On Windows the following are present but not on OS X:

//Flags used by the linker during the creation of static libraries.
CMAKE_STATIC_LINKER_FLAGS:STRING=

//Flags used by the linker during debug builds.
CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING=

Is there any significance in this?


What you need to remember here is that the versions of OpenSSL vary,

Post by Bioxydyn Dev
and that I don't test on Windows because I don't have access to that
platform (nor will I have access to that platform in the near future).
All I can do is guess that in Windows, you ought to really add those
as dependencies to things that need OpenSSL. I suspect that if these
DLLs are found in a common search path for libraries, that they would
be found properly without you having to do anything special. If you
have OpenSSL installed in a non-centralized path, then this would
cause you precisely this kind of trouble.

I still don't understand why, if I've built a static version of cpp-netlib,
why I don't need to add the additional libs on OS X when I build my
application. What am I missing?

[Dean Michael Berris]

Post by Bioxydyn Dev

Post by Dean Michael Berris

Post by Bioxydyn Dev
Hi Dean,
Thanks for your response.

Post by Dean Michael Berris
This is because Boost.Asio depends on OpenSSL, and all the
dependencies that OpenSSL has. If you're building in OS X and linking
OpenSSL, you're bringing in all the dependencies of OpenSSL too
(-lcrypt).

I understand that Boost.Asio depends on OpenSSL. I also understand that
cpp-netlib depends on Boost.Asio. As my application depends on cpp-netlib,
then it also depends ultimately on OpenSSL.
However, my question was why when I build my application on OS X, I don't
need to link in additional OpenSSL Libraries but on Windows I do (i.e.
ssleay32MTd.lib and libeay32MTd.lib). It is enough on OS X to link in
cppnetlib-uri l& cppnetlib-client-connections but on Windows it isn't.

This depends on how CMake finds the libraries. I think in 0.11.0-rc2
this has been "fixed" unless it hasn't been for MSVC. Generally the
default I think has switched from static linkage (which made things
simple) to dynamic linkage which is how you're getting these issues.

Where is the default specified?

In cpp-netlib/CMakeLists.txt.

Post by Bioxydyn Dev
I'm building static libs on both OS X and
//Dependencies for target
cppnetlib-client-connections_LIB_DEPENDS:STATIC=
//Dependencies for target
cppnetlib-server-parsers_LIB_DEPENDS:STATIC=
//Dependencies for target
cppnetlib-uri_LIB_DEPENDS:STATIC=
//Flags used by the linker during the creation of static libraries.
CMAKE_STATIC_LINKER_FLAGS:STRING=
//Flags used by the linker during debug builds.
CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING=
Is there any significance in this?

Nope.

Post by Bioxydyn Dev

Post by Dean Michael Berris
What you need to remember here is that the versions of OpenSSL vary,
and that I don't test on Windows because I don't have access to that
platform (nor will I have access to that platform in the near future).
All I can do is guess that in Windows, you ought to really add those
as dependencies to things that need OpenSSL. I suspect that if these
DLLs are found in a common search path for libraries, that they would
be found properly without you having to do anything special. If you
have OpenSSL installed in a non-centralized path, then this would
cause you precisely this kind of trouble.

I still don't understand why, if I've built a static version of cpp-netlib,
why I don't need to add the additional libs on OS X when I build my
application. What am I missing?

Because I suspect even the statically linked (archive) library in OS X
depends on the dynamic version of OpenSSL -- if you try `otool -L
library.a` it should show you that it may depend on the dynamic
version of libcrypt, and since libcrypt is found in OS X just fine by
the system linker then you have no problems linking it there. On
Windows, if your OpenSSL installation is not in the path that the
linker knows to look into, then it's going to fail to link it.

[Bioxydyn Dev]

Post by Dean Michael Berris
Because I suspect even the statically linked (archive) library in OS X
depends on the dynamic version of OpenSSL -- if you try `otool -L
library.a` it should show you that it may depend on the dynamic
version of libcrypt, and since libcrypt is found in OS X just fine by
the system linker then you have no problems linking it there. On
Windows, if your OpenSSL installation is not in the path that the
linker knows to look into, then it's going to fail to link it.

Investigation revealed that the Xcode linker will pick up a dynamic lib
before a static lib if both exist in the same directory. This is true even
if the project is set to link explicitly against the static library.

Thanks for your time, Dean.

[Bioxydyn Dev]

I've figured out the source of the confusion. On OS X, OpenSSL depends on
libssl and libcrypto. On Windows, it depends on libeay32xx and ssleay32xx.
i.e. The libraries have different names depending on the platform.
According to http://www.ski-epic.com/2007_notes_on_openssl/index.html, only
the authors know why that is.

[Dean Michael Berris]

Post by Bioxydyn Dev
I've figured out the source of the confusion. On OS X, OpenSSL depends on
libssl and libcrypto. On Windows, it depends on libeay32xx and ssleay32xx.
i.e. The libraries have different names depending on the platform. According
to http://www.ski-epic.com/2007_notes_on_openssl/index.html, only the
authors know why that is.

You understand that OpenSSL is hardly a well-maintained project right? :)

If only cpp-netlib didn't depend on Boost.Asio (or if somehow
Boost.Asio would support something other than OpenSSL for different
platforms) it would be a different situation. :D