[Boost-build] Need help with an odd <link>shared error

Subject: [Boost-build] Need help with an odd <link>shared error
From: Bob Walters (bob.s.walters_at_[hidden])
Date: 2011-08-17 13:39:12

I have a project (with its own Jamroot) which builds a library that is
dependent on several boost libraries.  Here's the Jamroot:

<begin Jamroot ===>
import common ;
import os ;

path-constant BOOST_ROOT : [ os.environ BOOST_ROOT ] ;
use-project /boostroot : $(BOOST_ROOT) ;

alias libboost_serialization : /boostroot//serialization ;
alias libboost_filesystem : /boostroot//filesystem ;
alias libboost_thread : /boostroot//thread ;
alias libboost_date_time : /boostroot//date_time ;
alias libboost_system : /boostroot//system ;

project stldb_lib
        : requirements
          <include>$(BOOST_ROOT)
          <include>.
          <toolset>msvc:<define>NO_STDINT_H
          <toolset>msvc:<define>_CRT_SECURE_NO_WARNINGS
          <toolset>msvc:<define>_SCL_SECURE_NO_WARNINGS
          <define>STLDB_TRACING
          <threading>multi
         ;

lib stldb
        : src/logging.cpp
          src/trace.cpp
          src/time_tracked.cpp
          src/timer.cpp
          src/bounded_interprocess_mutex.cpp
          src/db_file_util.cpp
          src/log_reader.cpp
          src/checkpoint.cpp
          libboost_serialization
          libboost_filesystem
          libboost_thread
          libboost_system
          libboost_date_time
          : <link>shared:<define>BOOST_STLDB_DYN_LINK=1
        ;

===<end Jamroot>

When I run this with either link=shared or link=static on Posix
systems (Linux, MacOS, and Solaris) the build works fine.

When I do bjam link=static on windows, it's also fine, however, when I
attempt bjam link=shared, I am getting an odd error about not being
able to open the serialization library.

command line: bjam toolset=msvc link=shared threading-multi variant=debug -q
result:
msvc.link.dll bin\msvc-9.0\debug\address-model-32\threading-multi\stldb.dll
LINK : fatal error LNK1104: cannot open file
'libboost_serialization-vc90-mt-gd-1_40.lib'
        call "c:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\vcvarsall.bat" x86 >nul
link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86
/subsystem:console
/out:"bin\msvc-9.0\debug\address-model-32\threading-multi\stldb.dll"
/IMPLIB:"bin\msvc-9.0\debug\address-model-32\threading-multi\stldb.lib"
   @"bin\msvc-9.0\debug\address-model-32\threading-multi\stldb.dll.rsp"

I don't think that the link error means that it can't find the file
(because I can see it there in the filesystem under the bin.v2 staging
directory).  I'm wondering instead if there is something specific to
windows that I have overlooked which is causing this.  For example, is
there a known limitation that the serialization library doesn't
supporting dynamic linking on windows, and thus no suitable library
for the link could be found.

I tried, just as an experiment, seeing if I could build the stldb
library with the static version of serialization via:

alias libboost_serialization : /boostroot//serialization/<link>static ;

That seemed to allow the link to proceed.

I also saw some of the past trac issues which suggested adding
<define>BOOST_ALL_NO_LIB to the project requirements
(https://svn.boost.org/trac/boost/ticket/4893 and
https://svn.boost.org/trac/boost/ticket/4901).  That also seemed to
allow the link to complete.

I'm trying to figure out if one of those approaches is what I should
be doing, or whether I'm just setting myself up for other problems.
Ideally, I would like to link with a dynamic version of lib
serialization (i.e. a version build with the same bjam parameters) and
not have to step around it this way, and I'm a bit confused as to why
this is only an issue on a windows machine.

I am using boost-jam-3.1.18-1-ntx86 with an older 1_40_0 boost library
which I have in source form, and have built using "bjam toolset=msvc
--with-system --with-serialization --with-thread --with-filesystem
--with-date_time --build-type=complete variant=debug stage"

Incidentally, I do need a dynamic library (specifically), as I'm
trying to dynamically load this via the native interface of scripting
languages.  No option to go purely static.

Any help or clarification on what I may be doing wrong greatfully appreciated.
- Bob