Boost Vc142

[Paz Warsager]

Im trying to compile one of my old projects (a raytracer, 10 years have passed since my last work on it!), so I've installed Visual Studio, downloaded a few libs (assimp, FreeImage, SDL) updated the code for the new libraries etc. The project compiles just fine, or so it seems.

There are many places it could come from. Project settings, build settings, project property sheets, even #pragma commands in the .cpp files. Thankfully these are all text files in modern projects, so scan your directory tree for that 141 or 142 string.

Thank you for replying! I could not find the issue, maybe auto-linking was trying to automatically find the file? Don't know. I've checked out the boost source and compiled it. I also had to do the same thing with assimp (I almost forgot how it was working with C++ XD).

The file boost-log-vc142-mt-x64-1_83.dll is usually part of the xServer installation but if the Microsoft Visual Studio Redistribution package is not installed on the server the error will show up in the module logfile.

If you are not interested building boost but just to install boost, then you can simply download them from SourceForge. You can download boost binaries for all Microsoft Visual Studio versions or for a specific one.

I'm a software engineer who likes to learn new things and work on projects. I have a Ph.D. in Information Engineering. I also enjoy reading and exploring watercolors and digital art. I share my ideas on my blog, PietroLC.com. I like to learn about many subjects, from science to philosophy. I use my curiosity to help me write good code and create interesting art. I'm always happy to talk with people who have similar interests.

Hi, I'm building Godot mono version with my custom module, I using boost library by adding the path in the SCsub file but always get an error message that says can't find the lib file. I'm pretty sure that the lib is just in the folder, how do I fix it?

in the last year i used boost in many programs. asio and beast. to be true atm not in godot. but never used as lib - boost is a header based library so i use the hpp's with includes like this "#include "

I think what is missing in the OPs post is adding the LIBS environment variable, so it knows which libraries it needs to link to. I think adding env.Append(LIBS=["libboost_locale-vc142-mt-s-x64-1_77.lib"]) after setting the library path may make it compile successfully.

Though for the automatic crash reporting module I made, I ended up using env.Append(LINKFLAGS=["path_to_libary.lib"] directly, as I couldn't quite get Scons to find the libraries automatically. I really good reference I found for how to setup a module with library dependencies is the Godot Steam library, as it has a really nice SCsub file that shows how the Steam libraries are included in the module.

Starting with 1.54.0 binaries are available packaged in the installers available here (pervious versions listed are packages of individual libraries for use with the deprecated boost-pro installer). These installers provide the listed binaries along with the complete source release (headers, source, documentation, tests, tools), so there is no need to install that from a zip file first.

The _b1, _b2, etc directories are the betas. In each release there is a log of the build output showing any errors. There is also a file "DEPENDENCY_VERSIONS.txt" that lists the versions of visual studio, python, etc that were used for the build.

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.

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).

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.

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.

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.

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.

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.

In this post, we look at how to build Boost.Python and Numpy. We look at it from a perspective where we want to use what we build as part of a bridge between SQL Server 2019 and Python. However, if you are not interested in SQL, the post should still give you some - hopefully - useful information.

Please note that I am a SQL dude, and my knowledge of Boost, Python and Numpy is limited at best. So take this post for what it is; the steps I took to successfully build Boost.Python and Numpy on a Windows box.

A language extension is a C++ dll acting as a bridge between SQL Server and an external runtime - in this case Python. To interact between C++ and Python you often use Boost, and for the SQL Server Python extension, Boost libraries are required.

Obviously, if you want to use what we do here to build a Python SQL Server Language Extension, you need the source code for the language extensions and SQL Server. That will be covered in a future post.

Boost is a set of C++ libraries complementing the C++ standard libraries. The Boost libraries provide support for tasks and structures such as linear algebra, pseudorandom number generation, multithreading, image processing, regular expressions, and unit testing.

Boost also allows us to interact between C++ and Python, via Boost.Python. In the Python extension, Boost is used - among other things - to interact with the runtime, execute scripts as well as to interact with numpy.

In Code Snippet 1 we see how I from command prompt have cd:ed into the Boost directory. I indicate that I want to use the Visual Studio 2019 toolset by defining the vc142 flag. When I execute the script, some information is output to the console, and when the script has finished, I see:

As mentioned above to build, we run b2.exe. If we were to cd into the Boost install directory and just do: b2, then we would build everything - and it would take a while. Here we are only interested in building Python, so we need to limit what b2 does.

An example of something going wrong was when I initially ran this code on Windows 10; the boost175 directory was created as expected. However, when I drilled down in the directory, I saw only a Python lib file, but no Numpy lib file. I knew there should be both Python and Numpy files, so something was clearly not right.

3a8082e126