Wt

Are you building Wt yourself, or are you using our binary builds?

Because wtisapi is intended to be linked in statically, you need to also link with its binary dependencies. That currently includes boost_thread. We don't provide the boost .lib files anymore with Wt 4, so I'll fix wtisapi so it doesn't have a binary dependency on Boost anymore.

Regards,

Roel

This was apparently caused by an include of boost::shared_mutex. The latest master on GitHub should generate a wtisapi lib that does not depend on Boost libs anymore (using std::shared_mutex instead of boost::shared_mutex there with MSVS 2015 or higher).

Regards,

Roel

With the latest 4.0.0 version, I'm glad to have switched to using your binary builds, which is using Wt as DLLs.

The link should have already occurred on your end, so I guess I'm thinking that a Wt header leads to a #pragma?

However, searching Include for boost, it's not obvious where it's coming from. I also can't find shared_mutex:

Find all "shared_mutex", Subfolders, Find Results 2, "C:\Dev\Couloir\3pLibs\wt-4\include", ".c;.cpp;.cxx;.cc;.tli;.tlh;.h;.hh;.hpp;.hxx;.hh;.inl;.rc;.resx;.idl;.vcxproj;*.inc"

Matching lines: 0 Matching files: 0 Total files searched: 740

I'm confused...

Are you saying that even if I'm using Wt.dll, wtasapi is still a static lib? If so, that would be fine, and maybe all I have to do is make a copy of the boost lib & name it correctly?

Frustrated with no answer, so I decided to try renaming my existing boost libs. However, as you can see from the attached image, it wasn't happy with just the thread lib.

Even after providing 4 boost libs, got this:

1>------ Build started: Project: HealthTracker.Wt.isapi.web, Configuration: Debug x64 ------
1>   Creating library \Dev\Product\x64\Debug\HealthTracker.Wt.isapi.web.lib and object \Dev\Product\x64\Debug\HealthTracker.Wt.isapi.web.exp
1>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>HealthTracker.Wt.isapi.web.obj : warning LNK4217: locally defined symbol ?WRun`Wt@@YAHHPEAPEADV?$function@$$A6A?AV?$unique_ptr@VWApplication@Wt@@U?$default_delete@VWApplication@Wt@@@std@@@std@@AEBVWEnvironment@Wt@@@Z@std@@`Z (int __cdecl Wt::WRun(int,char * *,class std::function<class std::unique_ptr<class Wt::WApplication,struct std::default_delete<class Wt::WApplication> > __cdecl(class Wt::WEnvironment const &)>)) imported in function main
1>wtisapid.lib(IsapiRequest.C.obj) : error LNK2019: unresolved external symbol BIO_free_all referenced in function "struct x509_st * __cdecl `anonymous namespace'::convertCertContext(struct _CERT_CONTEXT const &)" (?convertCertContext`?A0xbf667bf7@@YAPEAUx509_st@@AEBU_CERT_CONTEXT@@`Z)
1>wtisapid.lib(IsapiRequest.C.obj) : error LNK2019: unresolved external symbol BIO_new_mem_buf referenced in function "struct x509_st * __cdecl `anonymous namespace'::convertCertContext(struct _CERT_CONTEXT const &)" (?convertCertContext`?A0xbf667bf7@@YAPEAUx509_st@@AEBU_CERT_CONTEXT@@`Z)
1>wtisapid.lib(IsapiRequest.C.obj) : error LNK2019: unresolved external symbol d2i_X509_bio referenced in function "struct x509_st * __cdecl `anonymous namespace'::convertCertContext(struct _CERT_CONTEXT const &)" (?convertCertContext`?A0xbf667bf7@@YAPEAUx509_st@@AEBU_CERT_CONTEXT@@`Z)
1>wtisapid.lib(IsapiRequest.C.obj) : error LNK2019: unresolved external symbol X509_free referenced in function "public: virtual class Wt::WSslInfo * __cdecl Wt::isapi::IsapiRequest::sslInfo(void)const " (?sslInfo`IsapiRequest@isapi@Wt@@UEBAPEAVWSslInfo@3`XZ)
1>\Dev\Product\x64\Debug\HealthTracker.Wt.isapi.web.dll : fatal error LNK1120: 4 unresolved externals
1>Done building project "HealthTracker.Wt.isapi.web.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 9 up-to-date, 0 skipped ==========

You can try using your build of the (same version of the) boost libs and that might work. No guarantees, though. It may still crash at runtime. The symbols you are still missing are defined in the SSL libs, so you'll have to link with ssleay32.lib and libeay32.lib.

wtisapi.lib is indeed always linked statically, even when using a dynamically linked Wt, because it defines symbols that ISAPI uses.

Regards,

Roel

Adding ssleay32.lib and libeay32.lib resulted in a successful build.

However, I'm concerned about "might work. No guarantees, though. It may still crash at runtime".

What is the proper way to build ISAPI?

The current Wt 4.0.0 installer is broken w.r.t. wtisapi. The correct way to do it is to use the exact boost libs we used to build Wt, but those are missing. I'm thinking of releasing Wt 4.0.1 very soon with some fixes, and fixing our wtisapi build so it doesn't need boost anymore. The use of Boost.Thread is hidden in an internal class (src/web/Configuration.h), that's why you can't find it in our public header files.

If you also have a static build of Boost 1.65.1 built with Visual Studio 2017 (debug build for lib with -gd and release build for lib without -gd), then it could work. I guess you would notice rather quickly if it doesn't.

Regards,

Roel

ahh, thank you for the peace of mind. You understand well that bugs are no problem when there is transparency.

Another option for you might be to refactor the Boost dependencies into Wt.dll. That way, you'll have complete control over that. Just a thought.

I'll let you know the results of testing how it runs.

Another option for you might be to refactor the Boost dependencies into Wt.dll. That way, you'll have complete control over that. Just a thought.

That was exactly our intention. It was supposed to be statically linked into our dynamic libraries. It wasn't supposed to also end up as a dependency of wtisapi.

I'm getting a 404.0, which could indicate that I'm missing a DLL. Switching back and forth between this build and one from August (early version of Wt4) indicates that everything is ok with the IIS settings.

DLLs I've got in the folder: zlibd.dll, wtd.dll, ssleay32d.dll, libeay32d.dll.

Any DLL missing?

Or could it have something to with getting this warning:

1>------ Rebuild All started: Project: HealthTracker.Wt.isapi.web, Configuration: Release x64 ------
1>stdafx.cpp
1>HealthTracker.Wt.isapi.web.cpp
1>   Creating library \Dev\Product\x64\Release\HealthTracker.Wt.isapi.web.lib and object \Dev\Product\x64\Release\HealthTracker.Wt.isapi.web.exp
1>Generating code
1>All 16192 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
1>Finished generating code
1>HealthTracker.Wt.isapi.web.obj : warning LNK4049: locally defined symbol ?WRun`Wt@@YAHHPEAPEADV?$function@$$A6A?AV?$unique_ptr@VWApplication@Wt@@U?$default_delete@VWApplication@Wt@@@std@@@std@@AEBVWEnvironment@Wt@@@Z@std@@`Z (int __cdecl Wt::WRun(int,char * *,class std::function<class std::unique_ptr<class Wt::WApplication,struct std::default_delete<class Wt::WApplication> > __cdecl(class Wt::WEnvironment const &)>)) imported
1>HealthTracker.Wt.isapi.web.vcxproj -> \Dev\Product\x64\Release\HealthTracker.Wt.isapi.web.dll
1>HealthTracker.Wt.isapi.web.vcxproj -> \Dev\Product\x64\Release\HealthTracker.Wt.isapi.web.pdb (Full PDB)
1>Done building project "HealthTracker.Wt.isapi.web.vcxproj".
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Gunnar,

depends.exe can tell you what you're missing, if anything...

Best regards,

Wim.

I think the warning should disappear if you define WTISAPI_STATIC. Normally, when using wthttpd as a DLL, WRun is an imported symbol, so the Wt/WServer.h header file marks it as such. If you define WTISAPI_STATIC, it's no longer marked as imported, so the compiler won't warn you about it anymore.

Regards,

Roel

Wim, I used depends to figure out that it was looking for ssleay32.dll instead of ssleay32d.dll. However, it still didn't work, getting 404.0.

Will try adding WTISAPI_STATIC next.

Phew, I got it to work without fixing the warning (will do anyways).

LIBEAY32.dll

Wtd.dll

SSLEAY32D.dll

LIBEAY32D.dll

LIBHPDFD.dll

ZLIBD.dll

LIBPNG14D.dll

No big deal, but if you folks are doing 4.0.1 anyways, you could include the PDB file to avoid:

wtisapid.lib(Server.C.obj) : warning LNK4099: PDB 'wtisapid.pdb' was not found with 'wtisapid.lib(Server.C.obj)' or at 'C:\Dev\Product\x64\Debug\wtisapid.pdb'; linking object as if no debug info

I inadvertently forgot the "d" when adding LIBEAY32 to the "additional dependencies" of the debug build.

So, the correct list of required DLLs is (with or without "D" as appropriate):

Wtd.dll

SSLEAY32D.dll

LIBEAY32D.dll

LIBHPDFD.dll

ZLIBD.dll

LIBPNG14D.dll

Sadly, I started the build after you mentioned the thing about wtisapid.pdb being missing. We can look into that before the final 4.0.1 release in November.

It's safe to assume that all non-Wt DLLs in the bin folder are necessary when using wt.dll or wtd.dll, except for libmariadb.dll and libmariadbd.dll, which are of course only necessary when using wtdbomysql.dll or wtdbomysqld.dll.

Regards,

Roel