0

Whilst trying to install Boost Python on Visual Studio I have been getting few results. I was able to create the Boost.Python library and the boost_python...lib file has also been created which took me long to figure out how to achieve this.

However, now in visual studio, after adding the include and library path to the linker, I was not able to get a small test program to work.

When trying to run the following line of code:

Py_Initialize();
using namespace boost::python;
object main_module((handle<>(borrowed(PyImport_AddModule("__main__")))));

I am getting the following error

The program could not start because boost_python-vc141-1_65.dll is missing....

When I look in the boost folder just where the libraries are (in the stage folder) I can clearly see this file and I have linked the program against this folder.

I have tried various different Boost versions.

The latest stable build so 1.64 has the same problem as the beta 1.65. With a previous build, 1.61, I couldn't even get the Boost.Python to build.

I also tried different Python versions, 3.6 and now 2.7. I have uninstalled all other versions of Python so that the 2.7 version is the only one. I also made sure that the PYTHONHOME and PYTHONPATH are set in the system variables. ? Am i missing something important to get this Boost Python library to work? If any other information are needed please ask and I will add it, but since i'm unfamiliar with boost and linking in general i'm not sure what information is relevant.

1 Answer 1

2

On Windows there isn't /usr/shared directory, so boost build script can't install a dll library for everybody. So you're supposed to do the job yourself.

Your dll files must be in the same directory with your exe file. When you compiled boost, it created dll library in the boost output dir (search for this file). So, you have to copy this *.dll file to your output directory (where C++ compiler/linker create your *.exe) via custom build step or something.

If SafeDllSearchMode is enabled, the search order is as follows:

  • The directory from which the application loaded.
  • The system directory. Use the GetSystemDirectory function to get the path of this directory.
  • The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  • The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  • The current directory.
  • The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

If SafeDllSearchMode is disabled, the search order is as follows:

  • The directory from which the application loaded.
  • The current directory.
  • The system directory. Use the GetSystemDirectory function to get the path of this directory.
  • The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  • The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  • The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by
  • the App Paths registry key. The App Paths key is not used when computing the DLL search path.

Taken from here

Sign up to request clarification or add additional context in comments.

4 Comments

So if I copy paste the *.dll file into the same directory where my *.exe is I should be fine? Or what do you mean with "custom build step".
Yes, it should be fine, but your build processes should be automatic if you consider professional programmer's career. In order to make this automatic, you may add "copy" command as a custom build step. There are other options, though.
Ok i love you, I investigated about handling *.dll files and so much makes sense now that I didn't understand before. I have created a post build script which copies the *.dll files into the Target Directory
Also, forgot to tell, take note that there could be two or more versions of each dll file - slower, bigger, but containing debug symbols so you can enter into its functions using your debugger, and small and fast version for your release builds.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.