"schmitty9812003"
However, what I need is for the library to be a dll. So I changed the Jamfile to look something like this:
SOURCES = ...; dll sdtsxx : $(SOURCES) : <include>$(BOOST_ROOT) <include>$(TOP) <include>. <include>$(TOP)/Windows # to get bogus "unistd.h" <rtti>on <exception-handling>on <msvc><*><cflags>-TP # force to compile as C++ <gcc><*><cflags>"-x c++" # force to compile as C++ <gcc><*><define>VECTOR_ITERATOR_POINTER_NOT_EQUIVALENT : debug release ;
Unfortunately this gives me linking errors like this:
sb_Accessor.obj : error LNK2001: unresolved external symbol "public: class boost::filesystem::path __thiscall boost::filesystem::path::branch_path(void)const "(? branch_path@path@filesystem@boost@@QBE?AV123@XZ)
[warning: I'm not familiar with the sdtsxx libraries] Creating a DLL uses the linker, which (under Windows, anyway) checks all external dependencies. That means that adding [*1] DLL support to a build script means finding the sources of the unresolved externals and adding those libraries to the DLL link command. Now - how to do that in Jam. Uhhhhmm, I just don't know. It *looks* like there is an example in boost/libs/spirit/test/Jamfile where (AFAICT) it requires the boost_thread library if building a DLL with multi-threading enabled. I'm just making a semi-imformed guess, though - don't ask me how this Jam stuff really works! [*1] assuming the build script currently supports only static libraries, which can happily have unresolved externals (BTW, these get resolved at link time when the static library ultimately goes into an executable or DLL). BTW, I like running jam with the -d2 option to find out what's going on. Hope this helps. [snip] -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta