I'm trying to build and run tests using Boost.Test in Microsoft Visual Studio 14 2015 (on AppVeyor). My testcase is defined like this, so it should always pass and never throw:
#define BOOST_TEST_MODULE target_boost_test
#define BOOST_TEST_DYN_LINK
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_CASE(testcase)
{
BOOST_CHECK(true);
}
In the CMake script I set up linkage for the test as such:
find_package(Boost REQUIRED COMPONENTS unit_test_framework)
include_directories(${Boost_INCLUDE_DIRS})
...
add_executable(${UT_TARGET} ${UT_SOURCE})
target_link_libraries(${UT_TARGET} ${LIBRARIES} ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
The test compiles fine without any warnings but does not run and fails with a pretty unclear ***Exception: Other.
Test project C:/projects/msvc-boost-test/build
Start 1: target_boost_test
1/1 Test #1: target_boost_test ................***Exception: Other 0.08 sec
To reproduce easily I have set up a repo on GitHub with all the necessary files and an automated build job on AppVeyor to show the issue.
[Many thanks to #sehe for getting me on the right track]
In this case the exception was caused by the Boost.Test DLL not being found. I'm too unfamiliar with Windows as to know why the dynamic linker cannot find DLLs automatically. So far I have found two workarounds/fixes for this situation. The first is my preferred way.
1. Add the DLL path to PATH
In case of my AppVeyor YAML config this looked like this:
environment:
BOOST_LIBRARYDIR: "C:\\Libraries\\boost_1_59_0\\lib64-msvc-14.0"
PATH: "%BOOST_LIBRARYDIR%;%PATH%"
2. Copy the DLL to the same directory
Apparently the dynamic linker always searches the working directory (or the directory of the executable? I don't know). Copying the DLL over also worked, again in my AppVeyor YAML config this looked like this:
after_build:
- cmd: copy "%BOOST_LIBRARYDIR%\boost_unit_test_framework-vc140-mt-gd-1_59.dll" .
This is the less generic solution, as it requires explicitly specifying the name of the DLL. Thus, when switching from debug to release mode one also has to adapt the DLL name.
The contents of the repo from the question are summarized in this Gist in a working version.
Related
So, I've found really strange behaviour in CMake creating dependency on target_link_library..
It's hard to explain in one sentence, so here is a list of requirements (I hope this all will make sence in the end)
your project must have custom build type defined through CMAKE_CONFIGURATION_TYPES ('Tools' in this example)
you must have at least 3 targets:
executable (or simply main target) (test-exe in this example)
interface library which link to main target (this could be something other than INTERFACE library, but the next target must be linked to it via interface property only) (test-env in this example)
static library which links to the interface library with specific generator expression, which is depends on custom build type (something like that 'target_link_libraries(test-env INTERFACE $<$CONFIG:Tools:test-lib>)') (test-lib in this example)
Here is the code of the CMakeLists.txt file to make it little bit clearer:
cmake_minimum_required(VERSION 3.19.0 FATAL_ERROR)
project(multiconfiguration-test LANGUAGES CXX)
set(CMAKE_CONFIGURATION_TYPES Debug Release Tools)
set(CMAKE_CXX_FLAGS_TOOLS ${CMAKE_CXX_FLAGS_DEBUG})
set(CMAKE_EXE_LINKER_FLAGS_TOOLS ${CMAKE_EXE_LINKER_FLAGS_DEBUG})
set(CMAKE_STATIC_LINKER_FLAGS_TOOLS ${CMAKE_STATIC_LINKER_FLAGS_DEBUG})
add_library(test-env INTERFACE)
# EXCLUDE_FROM_ALL used to not build this target by default
add_library(test-lib STATIC EXCLUDE_FROM_ALL "test-lib.cpp")
target_link_libraries(test-env INTERFACE $<$<CONFIG:Tools>:test-lib>)
add_executable(test-exe "test-exe.cpp")
target_link_libraries(test-exe PRIVATE test-env)
(Files test-exe.cpp and test-lib.cpp are trivial, test-lib.cpp has a simple function, and test-exe.cpp declares this function and then calls it from main.)
When you would try to build this project with visual studio 2019/2017 generators (with "Tools" as configuration type of course: cmake --build . --config Tools), you will have next error:
LINK : fatal error LNK1104: cannot open file 'Tools\test-lib.lib' [<none_important_path_to_the_project>\test-exe.vcxproj]
And, what is important, you will not see in the terminal target test-lib being build.
So, what happened is target test-exe knows it must be linked against test-lib, but the build system doesn't know that target test-exe is dependent on target test-lib.
And now the most strange thing! If we will link this library like that: target_link_libraries(test-env INTERFACE $<$<CONFIG:Debug>:test-lib>) (so build type must be Debug), and still build project with Tools as a build type, you will see in the terminal that target test-lib is now building! (yes we have link error because test-exe can't find the function which is defined in test-lib, but this is at least expected)
So, what actually happens, the link flag of the target test-exe is correctly depends on the generator expression BUT, the actual build dependency, somehow, transforms any custom build type in this generator expression to the Debug.
Again this only happens with requirements I pointed up above, so it's not only the fault of generator expression, it's also connected to the interface dependency as well..
If we can't break any of the requirements, one possible solution will be to add direct dependency of test-lib target to test-env (like that: add_dependecies(test-env test-lib)), but this is not perfect, because even if we will use test-lib only then where is Tools as build type, we still will build this library each time, which can be undesired behavior.
I'm not really asking for solution here (but if you have one please share), I'm asking for the explanation why this even happening? Is this a bug or a really strange feature?
EDIT Small update I've found just now:
It must not even be the custom build type. The same bug can be encountered even with Release build type, so the final code can look as simple as this:
cmake_minimum_required(VERSION 3.19.0 FATAL_ERROR)
project(multiconfiguration-test LANGUAGES CXX)
add_library(test-env INTERFACE)
add_library(test-lib STATIC EXCLUDE_FROM_ALL "test-lib.cpp")
target_link_libraries(test-env INTERFACE $<$<CONFIG:Release>:test-lib>)
add_executable(test-exe "test-exe.cpp")
target_link_libraries(test-exe PRIVATE test-env)
and be build with next command: cmake --build . --config Release
Looks like a bug with the Visual Studio generator to me. I've just tested the Ninja Multi-Config generator both on Linux and on Windows and there cmake --build <build-dir> --config Release works just fine.
Background
I'm a complete newb with C++ and I've been running into one headache after another, so forgive me if this is incredibly simple and I'm just that dumb...
I have a project that should ultimately compile and run in Linux. Unfortunately after lots of issues with my C++ development environemnt (still unresolved), I gave up on trying to develop in Linux and moved to Windows Visual Studio 2017. My hope was to get my code working in Windows and then, since C++ is supposedly a portable language, it should just work in Linux with minimal changes.
For a day or so Visual Studio seemed to be working. I could write code, hit "compile", and like magic it would run. I threw together a few classes to construct a directed acyclic graph, used the standard library for a hash table, and then I tried to create a socket...
Windows and Linux use different libraries for sockets (<sys/socket.h> vs <winsock.h>) so I needed some way to abstract the differences, and I preferred a well-established standard. Googling around I found the Boost library that seemed to fit my needs... That's when everything went to hell.
My project setup
Because this project will be developed across a variety of platforms and IDEs (some people use Windows + Visual Studio, some people use Mac + Eclipse, and others use Linux + VIM) I opted to make it a CMake project. After several hours of reading and learning and research it seems like CMake should give me what I want (convenient and reproducible cross-platform builds with little or no dependency issues)
My source code (directly from the Boost Getting Started on Windows guide) is as follows:
CMakeProject2.cpp
#include <boost/lambda/lambda.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>
int main()
{
using namespace boost::lambda;
typedef std::istream_iterator<int> in;
std::for_each(
in(std::cin), in(), std::cout << (_1 * 3) << " ");
}
Per the Boost Getting Started on Windows guide, I downloaded Boost from here:
https://dl.bintray.com/boostorg/release/1.67.0/source/boost_1_67_0.zip
(interestingly, the Getting Started guide is titled "Boost Getting Started on Windows - 1.69.0", yet it linked to Boost versions 1.67.0)
After downloading and extracting the ZIP file, I had a whole mess of files - but no idea where to put them:
Attempts to Get It Working So Far
I tried to add the Boost library to my project, but none of the expected menu options were available:
Although I couldn't find a single page that warns you of this gotcha, apparently CMake projects don't have the elusive "Properties" window - and instead third party libraries must somehow be included via the CMakeLists.txt file
For starters, I copied the entire 540 MB contents of the Boost ZIP file to within my project under the folder name "Boost":
I then tried a series of different CMakeList.txt commands:
Per How do you add Boost libraries in CMakeLists.txt?:
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
find_package(Boost REQUIRED COMPONENTS lambda)
if(Boost_FOUND)
include_directories(${Boost_INCLUDE_DIRS})
add_executable(CMakeProject2 "CMakeProject2.cpp" "CMakeProject2.h")
target_link_libraries(CMakeProject2 ${Boost_LIBRARIES})
endif()
Per https://www.selectiveintellect.net/blog/2016/7/29/using-cmake-to-add-third-party-libraries-to-your-project-1:
include("Boost")
add_subdirectory("Boost")
add_subdirectory("boost")
add_subdirectory("Boost/boost")
add_subdirectory("Boost/boost/lambda")
target_link_libraries(boost)
target_link_libraries(Boost)
Per https://cmake.org/pipermail/cmake/2009-November/033249.html:
SET (Boost_FIND_REQUIRED TRUE)
SET (Boost_FIND_QUIETLY TRUE)
SET (Boost_DEBUG FALSE)
set (Boost_USE_MULTITHREADED TRUE)
set (Boost_USE_STATIC_LIBS TRUE)
SET (Boost_ADDITIONAL_VERSIONS "1.67" "1.67.0")
FIND_PACKAGE(Boost COMPONENTS lambda)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
I tried several other incantations (not being familiar with C++ or CMake as a tool) and either received errors from CMakeLists.txt, or from CMakeProject2.cpp about cannot open source file "boost/lambda/lambda.hpp". In fact, with regards to those "CMakeLists.txt" errors, after adding enough lines to my file I started to crash Visual Studio regularly. Note that I have an 8th generation i7, 32 gigabytes of RAM, and an M.2 NVMe hard drive -- so I was rather impressed that a few lines in a text file pissed off Microsoft enough to lock up my computer for 10 minutes at a time.
Failing all of that, I tried copying the files I needed directly into my project:
Now, again, I'm new to C/C++ development and everything that can go wrong has gone wrong. So far I've spent almost two weeks and barely managed to compile a single "Hello, World" app across two computers, three IDEs, and four compilers. I've yet to have any success including a third party library, from anywhere, of any popularity level or simplicity level, and actually compile a functioning program that references the library. So believe me when I say: I don't know the difference between a "header-only library" and... whatever the alternative is. I just know that, according to the Boost Getting Started on Windows guide, most of Boost is "headers only" and therefore I shouldn't have any build step -- it should be simple to use it. Furthermore, this example (using boost::lambda) is - per their instructions - a header-only library, and should therefore be extremely easy to use.
I now updated the source code slightly to look in the current directory, instead of looking in the system include directory (which, as far as I'm aware at this point, doesn't exist in Windows):
#include "boost/lambda/lambda.hpp"
#include <iostream>
#include <iterator>
#include <algorithm>
int main()
{
using namespace boost::lambda;
typedef std::istream_iterator<int> in;
std::for_each(
in(std::cin), in(), std::cout << (_1 * 3) << " ");
}
Now I can manually verify that this file exists (the file CMakeProject2\CMakeProject2\boost\lambda\lambda.hpp can be found in File Explorer) - yet I'm still getting errors:
cannot open source file "boost/lambda/lambda.hpp"
Some further Googling led me to update my CMakeLists.txt file once more, putting it in its current form:
# CMakeList.txt : CMake project for CMakeProject2, include source and define
# project specific logic here.
#
cmake_minimum_required (VERSION 3.8)
# Add source to this project's executable.
file(GLOB CMakeProject2_SRC
"*.h"
"*.cpp"
"**/*.h"
"**/*.cpp"
"**/*.hpp"
"boost/lambda/lambda.hpp"
)
add_executable (CMakeProject2 ${CMakeProject2_SRC})
#add_executable (CMakeProject2 "CMakeProject2.cpp" "CMakeProject2.h")
# TODO: Add tests and install targets if needed.
Despite this I'm still getting the error:
cannot open source file "boost/lambda/lambda.hpp"
At this point I'm ripping my hair out. What am I doing wrong? What do I not know? How is something as simple as the Boost-equivalent of "Hello, World" not working for me?
Following recipe should work
Download Boost binaries from official boost binaries location and install to say C:\Boost
Most times you do not need to build Boost on your own.
Your CMakeLists.txt should look like follows
cmake_minimum_required (VERSION 3.8)
project(boostAndCMake)
set(BOOST_ROOT "C:\Boost") # either set it here or from the command line
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
find_package(Boost REQUIRED COMPONENTS system) # header only libraries must not be added here
add_executable(CMakeProject2 CMakeProject2.cpp CMakeProject2.h)
target_include_directories(CMakeProject2 PUBLIC ${Boost_INCLUDE_DIRS})
target_link_libraries(CMakeProject2 ${Boost_LIBRARIES})
Because we used REQUIRED on the find_package call, CMake will fail execution and skip the rest of the script if it cannot be found. So no need to check Boost_FOUND. You need to check it, when you omit REQUIRED.
Now from the command line call from the directory where your script resides:
cmake -H. -Bbuildit -G "Visual Studio 15 2017" -DBOOST_ROOT=C:\Boost
This creates a build directory named buildit in the current directory, further creates a solution for Visual Studio 2017 inside the build directory and provides the setting for the variable BOOST_ROOT that is used in the find_package call to identify the Boost directory on your computer. To see what options are available on the find_package(Boost ...) call see FindBoost documentation in CMake.
Header Only Libraries
If your libraries are header only you need to omit them from the find_package(Boost ...) call. To see which libraries are not header only see this post.
Using newer Boost versions
If your CMake installation cannot find the requested version, e.g. 1.69.0, but supports the naming scheme of the more recent Boost version you can use it with set(Boost_ADDITIONAL_VERSIONS "1.69.0" "1.69"). Last change of the Boost naming scheme was from 1.65.1 to 1.66.
Here's a working setup for Boost 1.68 with CMake 3.12. Boost 1.69 is apparently "too new" for cmake to detect it properly. Since boost is not buildable by cmake, cmake itself must provide a FindBoost.cmake module that must keep up with boost changes.
So anyway, the CMakeLists.txt is as small as this:
cmake_minimum_required(VERSION 3.11)
project(foobar)
find_package(Boost 1.68 REQUIRED)
add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC Boost::boost)
Of course, you can split it in many subdirectories.
Invoking CMake in the command line should look like this:
cmake -DCMAKE_PREFIX_PATH=path_to_local_directory ..
Where path_to_local_directory is the installation path of all library you want to depend on. It will work for Boost, nlohmann_json, glfw3, Qt, you name it *(1). For my case, it was C:/local/ and another case was ../external/ (yes, it can be a directory local to the project!)
Let's take a peek at my own C:/local/:
ls -l /c/local/
total 12
drwxr-xr-x 1 myself 197609 0 May 26 2018 boost_1_67_0/
drwxr-xr-x 1 myself 197609 0 Sep 5 02:02 boost_1_68_0/
WARNING: Ensure your compiler architecture is the same as the installed boost version. Or else cmake will simply not find it.
I think that about it. The next CMake version (3.14) should work with the latest boost.
*(1) The said library will either need to export it's CMake target or you must provide a FindXXX.cmake
I'm using CMake 3.22 with Boost version 1.78.
The simplest solution is to set the Boost_INCLUDE_DIR when calling Cmake:
cmake -DBoost_INCLUDE_DIR=boost
Pass the directory to where the Boost libraries are. If you're using Visual Studio you can also set this in your CMake Settings:
Or, in the CMakeSettings.json file:
"cmakeCommandArgs": "-DBoost_INCLUDE_DIR=boost",
In my opinion, this is better than using the set function because you're not hard coding the path.
Add a target_include_directories(CMakeProject2 PRIVATE .) into your CMakeList.txt.
The . is the relative path of boost/lambda/lambda.hpp from CMakeLists.txt
And you should not add any .hpp file to the source list.
I am having some trouble running a simple test with catch2 using CMake. Since catch is header only I got the impression that it is easily dropped into any project so i thought I'd just include it like a normal header file.
Project structure:
-build
-external
-Catch2
catch2.hpp
CMakeLists.txt
tester.cpp
CMakeLists.txt:
cmake_minimum_required(VERSION 3.12)
project(Test VERSION 1.0.0)
include_directories(external)
enable_testing()
add_executable(tester tester.cpp)
add_test(Tester tester)
tester.cpp:
#define CATCH_CONFIG_MAIN
#include "Catch2\catch.hpp"
TEST_CASE( "1 is 1" ) {
REQUIRE( 1 == 1 );
}
Output:
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.03 sec
The following tests FAILED:
1 - Tester (Exit code 0xc0000139
)
Errors while running CTest
Obviously the test should pass, but it does not. Since I am a beginner both in the realm of CMake and catch2 I am having a hard time to pinpoint the issue. What I can say for certain is that catch.hpp is found and there is no linker errors, it just return some error code.
I looked around and found this:
CMake Header from library not found when implementing in catch test case
But it has no answers, and the author does not seem to have the same problem anyway.
This is how I build and run the tests (standing in the build directory):
cmake .. -G "MinGW Makefiles" && mingw32-make && ctest
Any help is appretiated :)
Alright, i removed catch and just played around with mingw and apparently i get the same error just by using std::string. Someone said that it has to do with missing DLL files. I ran dependency walker on the executable and indeed a bunch of DLLs was missing. I didn't now what to do or where to get these so i ditched mingw and tried the cygwin approach.
But using cmake with cygwin i did not find any compatable generators for my development environment (windows).
I then switched to generating a visual studio project instead (which i was avoiding from the start because i did not want to develop in an IDE). But i found out that i can use msbuild to build the executable from the generated visual studio project and it works like a charm, with catch.
I am trying to make a C++ program that uses the OpenSubdiv library from Pixar: https://github.com/PixarAnimationStudios/OpenSubdiv
I have managed to build the library, including the "tutorials", which uses the library.
Both OpenSubdiv and my own program is built with CMake (which I have some, but not much experince with). For testing purposes, I have a project folder where my C++ code lies, and I inside this folder I also have an OpenSubdiv folder where I have built the library in OpenSubdiv/build. The C++ code That I am using for testing purposes is identical to one of the tutorials provided by pixar with opensubdiv, called "far_tutorial_0.cpp". This tutorial compiles and work fine inside the Opensubdiv folder, with the very long and complex CMake script intended to install the entire library. However, when I move it out of the Opensubdiv folder, and try to compile with a simple CMake script, I get problems. This is the CMake script that I use:
cmake_minimum_required (VERSION 2.6)
project (test)
add_executable(test test.cpp)
include_directories(OpenSubdiv/build)
target_link_libraries(test osdCPU)
This manages to compile the code without any error messages, but when I try to execute the code, it says "error while loading shared libraries: libosdCPU.so.3.0.0.beta: cannot open shared object file: No such file or directory".
I have tried change the library name to "osdCPU.so.3.0.0.beta" (which gives an error while compiling), and I have tried using both library names (which gives the same error). The file "libosdCPU.so.3.0.0.beta" is inside the OpenSubdiv/build/lib folder, right next to "libosdCPU.so".
Does anybody know what's wrong?
You also have to provide the location of the library osdCPU with the CMake command link_directories.
Moreover, I encourage you to formalize your code with specific variables like this (including a cache variable you can modify through the command ccmake) :
set(osdCPU_PATH_DEFAULT "/default/path/to/osdCPU")
set(osdCPU_PATH "${osdCPU_PATH_DEFAULT}" CACHE PATH "Path to osdCPU")
set(osdCPU_INCLUDE_DIRS ${osdCPU_PATH}/include)
set(osdCPU_LIBRARY_DIRS ${osdCPU_PATH}/lib)
set(osdCPU_LIBRARIES osdCPU)
Then you can call
include_directories(${osdCPU_INCLUDE_DIRS})
link_directories(${osdCPU_LIBRARY_DIRS})
# ...
target_link_libraries(test ${osdCPU_LIBRARIES})
I'm trying (for a few days now) to build a DLL generated from C++ code with boost/python to be used by python. I am a Student from Germany and had mostly to do with Java until now (I wrote some basic OpenGL and gimp filter stuff before in C++). So pardon me in advance for bad english or C++ beginner mistakes. I mean, programming with Java really is a lot more comfortable in comparison to C++. But enough of the skirmish.
The error:
LINK : fatal error LNK1104: File "boost_python-vc110-mt-gd-1_53.lib" could not be openend
My presets:
-using MS Visual Studio 2012 (11.0)
-using boost_1_53_0
-using python2.7 (I heard 3.3 may cause some Problems)
What I did:
Installed python and added it to PATH. Then created a new empty project in VS and a class file "Test.cpp" with following content as described on the boost tutorial page:
char const* greet()
{
return "hello world";
}
#include <boost/python.hpp>
BOOST_PYTHON_MODULE(Test)
{
using namespace boost::python
def("greet", greet);
}
Then came the new part for me, in VS Project Properties:
Configuration Properties > General > Configurationtype > Dynamic Library (.dll)
C/C++ > General > Addition Includedirectories > C:[..]\boost_1_53_0
Linker > General > Additional Library Directories > C:[..]boost_1_53_0\stage\lib
From the error I am assuming i did something wrong with Linker or Include. I also changed the Linker > General > Additional Library Directories to boost_1_53_0\libs because i wasn't sure, but the same error occured. And yes, I correctly included python. I am also not sure if i have to put something else beside python into Linker > Input for boost.
Then I build boost with bjam with no options except msvc-11.0 to be sure to have everything i need (though I read that boost/python doesn't need an extra build) and still got the same error. Can someone help me? I would love to have a step by step description of what to do. I am really despairing of this.
Btw.: I had the same error as this guy a few days before Linker error LNK1104 with 'libboost_filesystem-vc100-mt-s-1_49.lib' then stopped working on it and as I started again I got my brand new error (I can't tell you how this happened).
Since it is looking for a static library, add BOOST_PYTHON_STATIC_LIB flag, go to VS properties -> Preprocessor -> Processor definition, add BOOST_PYTHON_STATIC_LIB flag.
You need to create a "user-config.jam" file that indicates where the python headers and libs can be found by Boost.Build. You can create it in your boost_1_53_0/ directory with the following contents:
# Configure specific Python version.
using python : 2.7
: C:/Python27/python.exe
: C:/Python27/include #directory that contains pyconfig.h
: C:/Python27/libs #directory that contains python27.lib
: <toolset>msvc ;
Then from that boost_1_53_0/ directory you need to invoke b2 like this in order to build the missing library:
b2 toolset=msvc-11.0 --with-python variant=debug runtime-debugging=on link=shared --user-config=user-config.jam stage
(although I would recommend b2 toolset=msvc-11.0 --with-python --user-config=user-config.jam --build-type=complete stage so you can get in one step all the configurations that you might need in the future)
Once you have the libraries you need to add the directories to Visual Studio ( both to boost and to python).
Once you have successfully built the module you need to rename it to Test.pyd (exact name you used in BOOST_PYTHON_MODULE. If you have the python and Boost.Python libraries in your PATH or in your current directory you will be able to use the script in the tutorial:
import Test
print Test.greet()
and get the familiar "hello world".
Note that I'm very thankful for your tries but none of your answers helped. A fellow student then gave the hint for the right answer to me and some steps are really easy, others I don't understand, but it works now.
First Problem was: The new boost 1.53.0 does not work with Python27 or older. I then linked it with Python33 and had the build error removed.
But of course the build version didn't work without an error. As I tried to start my helloboost.py which imports from the .pyd built by VisualStudio and invokes the greet method, the following error occured:
ImportError: DLL load failed: The specified module could not be found.
As i checked the hello_ext.pyd with the dependency walker and wildly copy pasted around, I found out it needs the boost_python-vc110-mt-gd-1_53.dll (probably depending on what you need and built with bjam before) in the same folder. It worked then. Maybe someone can explain why nowhere was explained that I need this dll in the same folder as the pyd (or did I miss something? Is it just because I made a mistake before?)
Anyhow, I'm very glad it works now and hope it helps other people.
You probably will have worked this out by now - however:
When a .exe looks for a .dll to load no path is specified. Therefore a .dll must be in the search path for the file.
Also: I was trying to build 1.49 libs for Visual Studio 2013 - and kept getting the LNK error from my project. I don't know who suggested it on stackoverflow but someone\something gave me the idea to copy build system from a more recent boost which knows how to make .libs for more recent environments. (thank you)
I had to copy the boost build system from a 1.58 after running bootstrap in 1.58, copy b2, bjam and boost-build.jam to the earlier boost folder root to replace the same named files there. Also you will need to copy the later tools\build folder to support the build system.
Noting here in the hope it might help someone else in a similar cituation I found myself in.
See: Search Path Used by Windows to Locate a DLL