
I am making a test program in order to test the operation of the serialization library when serializable type is serialized from within a dynamically loaded DLL. I've made a DLL which serializes to a polymorphic_?archive. I'm going to make a test program which calls the DLL. Here are my questions: [Test] My DLL has included <boost/test/test_tools.hpp> and test tool macros. Things compile fine. When I try to link I get a failure because I've got not test_main - I'm using the Test Execution Monitor. Now that I think about it - its not clear at all how to address this. Suppose the above is resolved. I run my test and I get a failure in the DLL, will the exception propagate across the DLL interface into the main executable? I would hope so buf I don't know for sure. [bjam] Assuming the above issues are resolved I will have two program modules: test_dll_main and test_dll_A (dll to serialize class A). Not each bjam target lands in its own directory of the form bin/boost/libs/serialization/<test_module_name>.test/<compiler_name>/debug/threading-multi/test_module_name.exe I would guess that the dll lands in bin/boost/libs/serialization/<test_dll_name>.test/<compiler_name>/debug/threading-multi/test_dll_name.dll So in my main test module I would need something like dlopen or LoadLibrary ("bin/boost/libs/serialization/<test_module_name>.test/<compiler_name>/debug/threading-multi/test_module_name.exe") which is going to be pretty inconvenient or make sure that the test_dll is placed in the same target directory as test_main - which I don't know how to make bjam do. Is there any information on how to go about building and testing DLLS/Shared Libraries? Robert Ramey

"Robert Ramey" <ramey@rrsd.com> writes:
It should "just work." I do this kind of thing with Boost.Python all the time. Just make your test depend on the library; Boost.Build will automatically make sure the DLL/.so ends up in the PATH/LD_LIBRARY_PATH (or some other variable on other *nixes). -- Dave Abrahams Boost Consulting www.boost-consulting.com

Unfortunately I do not know any solution to this. Apparently when DLL on windows is linked - everything should be resolved. That's the primary reason why there is no DLL version of Boost.Test component on Windows. I still looking for some kind of workaround - it will definetly require different test initiation interface. Gennadiy
participants (3)
-
David Abrahams
-
Gennadiy Rozental
-
Robert Ramey