Boost logo

Boost Users :

From: Raoul Gough (yg-boost-users_at_[hidden])
Date: 2003-08-22 05:59:54

"schmitty9812003" <schmitty9812003_at_[hidden]> writes:

> 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++
> : 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_at_path@filesystem_at_boost@@QBE?AV123_at_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.


Raoul Gough
"Let there be one measure for wine throughout our kingdom, and one
measure for ale, and one measure for corn" - Magna Carta

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at