Support #2015
closedTesting SSL
Description
After installing Wt 3.3.0 along with OpenSSL and GraphicsMagick on Windows 7, I'm having trouble testing their functionality. I need a hint. I've been able to successfully run some examples such as simplechat.wt, in http, but editing the project command parameters generates exception when running:
--https-address=0.0.0.0 --https-port=443 --deploy-path=/simplechat --docroot=.
Also need to test GraphicsMagick and, shortly, Libpango, Libharu, Postgres, Firebird, etc. I'm working off of this wiki page, revising locally as I go. Hope to have a more complete version of that wiki page after I'm done with the installation and examples testing, which I'll use to update it.
Updated by Bud T over 11 years ago
That is, this wiki page: Installing Wt on MS Windows... I suppose the answer to the first question is to use another web server; since the wthttpd connector probably doesn't support ssl?
Updated by Wim Dumon over 11 years ago
The FAQ contains the answer to your question:
http://redmine.emweb.be/projects/wt/wiki/Frequently_Asked_Questions#Q-How-do-I-use-the-built-in-HTTPS-server-in-wthttpd
BR,
Wim.
Updated by Bud T over 11 years ago
Presently I'm not using SSL yet, and just building a test program like the hello world program in this tutorial listed on this wiki: http://andres.jaimes.net/780/how-to-create-a-first-application-using-wt-witty/ using VisualStudio 2010.
I have compiled successfully with OpenSSL (all versions present, as installed from the OpenSSL installer) and run some simple programs testing boost without errors. When attempting to build the Debug configuration of this hello world application there are many errors related to the calls to the openssl libraries, as shown below. I'm not sure why.
1> main.cpp
1>Link:
1> Creating library C:\visual studio 2010\Projects\test\Debug\hello_world.lib and object C:\visual studio 2010\Projects\test\Debug\hello_world.exp
1>wthttpd.lib(Connection.obj) : error LNK2019: unresolved external symbol _ERR_reason_error_string referenced in function "public: virtual class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall boost::asio::error::detail::ssl_category::message(int)const " (?message`ssl_category@detail@error@asio@boost@@UBE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@H`Z)
...
1>wtd.lib(SslUtils.obj) : error LNK2019: unresolved external symbol _PEM_read_bio_X509 referenced in function "struct x509_st * __cdecl Wt::Ssl::readFromPem(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?readFromPem`Ssl@Wt@@YAPAUx509_st@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@`Z)
1>wtd.lib(SslUtils.obj) : error LNK2019: unresolved external symbol _BIO_puts referenced in function "struct x509_st * __cdecl Wt::Ssl::readFromPem(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?readFromPem`Ssl@Wt@@YAPAUx509_st@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@`Z)
1>C:\visual studio 2010\Projects\test\Debug\hello_world.exe : fatal error LNK1120: 85 unresolved externals
1>
1>Build FAILED.
I have the wtd.lib and wthttpd.lib files listed as "Additional Dependencies" under Linker > Input.
kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;%(AdditionalDependencies);wtd.lib;wthttpd.lib
If I remove those files from this field then a different but similar set of errors are produced, also when building for Debug, some shown below:
1>------ Rebuild All started: Project: hello_world, Configuration: Debug Win32 ------
1>Build started 7/15/2013 10:49:31 PM.
1>_PrepareForClean:
1> Deleting file "Debug\hello_world.lastbuildstate".
1>InitializeBuildStatus:
1> Touching "Debug\hello_world.unsuccessfulbuild".
1>ClCompile:
1> main.cpp
1>main.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall Wt::WApplication::~WApplication(void)" (??1WApplication`Wt@@UAE`XZ) referenced in function __unwindfunclet$??0ControlExample`@QAE@ABVWEnvironment@Wt@@`Z$0
1>main.obj : error LNK2019: unresolved external symbol "public: __thiscall Wt::WText::WText(class Wt::WString const &,class Wt::WContainerWidget *)" (??0WText`Wt@@QAE@ABVWString@1@PAVWContainerWidget@1@`Z) referenced in function "public: __thiscall ControlExample::ControlExample(class Wt::WEnvironment const &)" (??0ControlExample`@QAE@ABVWEnvironment@Wt@@`Z)
...
1>main.obj : error LNK2019: unresolved external symbol "int __cdecl Wt::WRun(int,char * *,class boost::function<class Wt::WApplication * __cdecl(class Wt::WEnvironment const &)>)" (?WRun`Wt@@YAHHPAPADV?$function@$$A6APAVWApplication@Wt@@ABVWEnvironment@2@@Z@boost@@`Z) referenced in function _main
1>C:\visual studio 2010\Projects\test\Debug\hello_world.exe : fatal error LNK1120: 26 unresolved externals
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:08.25
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Updated by Bud T over 11 years ago
I should also remark that I was able to install and test Wt examples without errors immediately prior to this project build, on same machine. I don't understand why this simple test program in another test solution/project doesn't build, as I followed similar protocol in setting it up to that used for the Wt.sln and example projects.
Updated by Wim Dumon over 11 years ago
Hello Brad,
Note that in MSVS, the 'Additional Libraries' for Debug/Release/... configurations are different fields, so if you add libraries to one of them, you usually also have to add them to different configurations.
I use a precompiled OpenSSL, and link to the following libraries for debug builds:
c:\openssl\lib\VC\ssleay32MDd.lib
c:\openssl\lib\VC\libeay32MDd.lib
For release builds, the libraries are:
c:\openssl\lib\VC\ssleay32MD.lib
c:\openssl\lib\VC\libeay32MD.lib
If you build Wt as a static library, you do have to repeat the libraries that Wt depends on in your own project too.
If you build Wt as a shared library, you don't have to repeat the libraries that Wt depends on in your own project.
BR,
Wim.
Updated by Bud T over 11 years ago
Thanks Wim.
I installed Wt using default static.
My boost binary installation included all versions of static and dynamic libs.
My Wt build included the files that you have listed, for fields like SSL_LIB_DEBUG: C:/OpenSSL-Win32/lib/VC/ssleay32MDd.lib.
You are saying that my static build requires those files to be linked in my project, within a field "Additional Libraries"? That is fine, but I don't see anything under Linker > General (it only has field for "Additional Library Directories" in which directories like "C:\Program Files (x86)\boost\boost_1_47\lib" and "C:\Program Files (x86)\WT\lib" are to be listed).
Neither do I see such a field under Linker > Input (the only similar field is "Additional Dependencies" in which files like 'wtd.lib' are to be listed without full path).
It is therefore not clear to me how to link to those libraries as you have indicated. I tried adding those files to Linker > Input > "Additional Dependencies" field and got this error: "LINK : fatal error LNK1104: cannot open file 'ssleay32MDd.lib'", which I know is present in this directory: "C:\OpenSSL-Win32\lib\VC" (February create date); and, now that I look, it is also present under "C:\OpenSSL-Win32\lib\VC\static" (recent, July, create date), which seems odd. I even added a value for "PATH=C:\OpenSSL-Win32\bin" to the Configuration Properties > Debugging > Environment field and same error returned.
Brad
Updated by Wim Dumon over 11 years ago
MSVS documentation should point you in the right direction here.
Either put the full path in the 'Additional libraries' field, or add the path to the libraries to the 'Additional Libraries Directories' field (Linker->General).
BR,
Wim.
Updated by Bud T over 11 years ago
Wim, there isn't any field for "Additional Libraries". I placed the paths to the libraries under "Additional Libraries Directories" field, as you just suggested, and tried building with the file names in "Additional Dependencies" as well as not. The results are the same as those pasted above; ending with the same "fatal error LNK1120: 85 unresolved externals". Would you please do me a favor and reread my last post carefully and reply with your best suggestion? I feel as though I've tried just about everything already. Thanks.
Updated by Wim Dumon over 11 years ago
Hello Brad,
Where I wrote 'Additional Libraries', I meant 'Additional Depencencies'.
As long as you see LINK : fatal error LNK1104: cannot open file 'ssleay32MDd.lib'
, there is something wrong with 'Additional Dependencies' and/or 'Additional Libraries Directories'. The easiest around this is to place the full path to the .lib file in the 'Additional Dependencies' directory. Put there the exact same library as is used in the Wt project.
BR,
Wim.
Updated by Bud T over 11 years ago
Wim, I did as you suggested (full path and file name in "Additional Dependencies") and those ssl related link errors are gone now. Still just a few left over, though, for this one function call. Do these look familiar?
1>ClCompile:
1> main.cpp
1>Link:
1> Creating library C:\Visual Studio 2010\Projects\test\Debug\hello_world.lib and object C:\Visual Studio 2010\Projects\test\Debug\hello_world.exp
1>wthttpd.lib(Reply.obj) : error LNK2019: unresolved external symbol _deflateEnd@4 referenced in function "public: virtual __thiscall http::server::Reply::~Reply(void)" (??1Reply`server@http@@UAE`XZ)
1>wthttpd.lib(Reply.obj) : error LNK2019: unresolved external symbol _deflateInit2_@32 referenced in function "private: void __thiscall http::server::Reply::initGzip(void)" (?initGzip`Reply@server@http@`AAEXXZ)
1>wthttpd.lib(Reply.obj) : error LNK2019: unresolved external symbol _deflate@8 referenced in function "private: void __thiscall http::server::Reply::encodeNextContentBuffer(class std::vector<class boost::asio::const_buffer,class std::allocator<class boost::asio::const_buffer> > &,int &,int &)" (?encodeNextContentBuffer`Reply@server@http@@AAEXAAV?$vector@Vconst_buffer@asio@boost@@V?$allocator@Vconst_buffer@asio@boost@@@std@@@std@@AAH1`Z)
1>C:\Visual Studio 2010\Projects\test\Debug\hello_world.exe : fatal error LNK1120: 3 unresolved externals
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:07.56
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Updated by Wim Dumon over 11 years ago
- Status changed from New to Resolved
The deflate functions are functions from zlib. Just like you linked to the ssl libraries, you also need to link your project to the zlib libraries.
BR,
Wim.
Updated by Bud T over 11 years ago
Yeah, that fixed it. Using full path with file name seems to be the trick. One thing that I don't understand right now, though, is why, if Wt defaults to building static link libraries then why does my project build with "Multi-threaded Debug DLL (/MDd)" for runtime libraries but doesn't build for "Multi-threaded Debug (/Md)" - even when I point to the static openssl libs files? Seems to me like it shouldn't build for dynamic if it is building for static; not vice versa.
Updated by Wim Dumon over 11 years ago
Hello Brad,
You're diving in the dirty dungeons of MSVS here.
For any library that your project links to, you can choose whether you want to link to a static or dynamic versions, and there are many reasons to choose for the one vs the other. This is true for libraries like Wt, OpenSSL, zlib, but also the visual studio C runtime libraries, the so-called CRT libraries, which contain things like malloc, free, fopen, ...
The options /MT, /MD, /MTd and /MDd select which version of the C runtime library you want to link to. You can freely pick one, but never mix multiple types of crt in one application. The linker will print a warning if you do. The reason is, that the data structures of those libraries are not compatible. For example, a pointer to a memory region malloced by the malloc implementation e.g. MDd, cannot be freed by the free implementation of e.g. MT. If you pass pointers around your application and use them freely, you will see that things will crash. Likewise for files opened by fopen() of one type of CRT, which cannot be deleted by the close() of another CRT, and many others.
So can you use MD in your application and link to a static OpenSSL? Yes, provided that your OpenSSL was compiled with MD. Can you use MT in your application and link to a OpenSSL DLL? Yes, provided that your OpenSSL was compiled with MT (at least I think so, it may also be not ok). The two choices (static/dynamic openssl vs static/dynamic CRT) are orhtogonal. Same goes for any other library, like e.g. wt.
Note, if you are really really careful, you can mix different CRTs in one application, but I've never found a clear description from MS of what is allowed or what not. So keep your life simple and don't do it.
Microsoft recommends to use dynamically linked CRTs, so that they can provide system-wide patches to the C runtime library.
BR,
Wim.
Updated by Koen Deforche over 11 years ago
- Status changed from Resolved to Closed
- Target version set to 3.3.1