[Boost-build] build of shared libs not producing .lib file.

Subject: [Boost-build] build of shared libs not producing .lib file.
From: Bob Walters (bob.s.walters_at_[hidden])
Date: 2009-09-21 19:52:10

Having difficulty using Boost.Build (1_39_0 with bjam 3.1.17
downloaded binary) to build a pair of libraries in 2 projects with one
depending on the other.  The first library, 'stldb' depends on 5 boost
libraries.  The second library stldb-jni  depends on stldb, and thus
indirectly on boost. The stldb-jni library is loaded via the Java
native interface, and thus must be built as a  shared library, while
the stldb library has no compulsion either way.  The problem I'm
having is specific to Windows - no problem at all on Linux w/ various
flavors of gcc.

The problem is that when the stldb.dll is built, there is no
corresponding stldb.lib built, which seems to be what the subsequent
build is trying to link with.

-----Start of Jamroot-----
import os ;

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

alias boost_thread : /boost//thread ;
alias boost_date_time : /boost//date_time ;

project bar
 :
 requirements
 <include>$(BOOST_ROOT)
 ;

lib foo
 :
 foo.cpp
 boost_thread
 boost_date_time
 ;

exe bar
 :
 main.cpp
 foo
 ;
-----End of Jamroot-----

-----Start of foo.cpp-----

#include <boost/thread/thread.hpp>
#include <boost/lambda/lambda.hpp>

extern int foo()
{
 int result = 0;

 boost::thread t(boost::lambda::var(result) = 1);

 t.join();

 return result;
}
-----End of foo.cpp-----

-----Start of main.cpp-----
int foo();

int main(int, char*[])
{
 return foo();
}
-----End of main.cpp-----

My command line for the build:
bjam -q --without-python toolset=msvc variant=debug link=shared

When the above is run with link=static, everything works fine.  Upon
trying to build a shared copy, the dll is built, but the dynamic
linking is failing with an error cuased by the lack of a .lib file:

msvc.link.dll bin\msvc-9.0\debug\threading-multi\foo.dll
msvc.manifest.dll bin\msvc-9.0\debug\threading-multi\foo.dll
msvc.link bin\msvc-9.0\debug\threading-multi\bar.exe
LINK : fatal error LNK1181: cannot open input file
'bin\msvc-9.0\debug\threading-multi\foo.lib'

        call "C:\Program Files\Microsoft Visual Studio
9.0\VC\vcvarsall.bat" x86 >nul
link /NOLOGO /INCREMENTAL:NO /DEBUG /subsystem:console
/out:"bin\msvc-9.0\debug\threading-multi\bar.exe"
@"bin\msvc-9.0\debug\threading-multi\bar.exe.rsp"
        if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL%

...failed msvc.link bin\msvc-9.0\debug\threading-multi\bar.exe...
...failed updating 1 target...
...updated 1 target...

What I can't figure out is how to get the .lib file that you normally
see alongside the boost DLLs in stage/lib after a successful boost
installation.  i.e. The files that facilitate linking with the DLL
that has been built.

When I try to build the subsequent library without the .lib, it tries
linking dynamically, and yields the predictable error:

LINK : fatal error LNK1181: cannot open input file
'C:\workspaces\stldb_head\stldb_lib\bin\msvc-9.0\debug\threading-multi\stldb.lib'

I've tried getting the later library to link statically by changing
the library reference to "/stldb_lib//stldb/<link>static", I get rid
of that error, but start getting:

LINK : fatal error LNK1104: cannot open file
'boost_date_time-vc90-mt-gd-1_39.lib'

Couldn't explain why it would suddenly start having problems finding
boost libraries.  Thought the msvc linker might be inferring the need
to link to that library from some dependency, then raising an error
because it can't see a corresponding dll on the path.  So I added my
installation directory (../dist) to my path, and that problem actually
went away, to be replaced by :

LINK : fatal error LNK1104: cannot open file 'advapi32.lib'

Added C:\Windows\system32 to the path, and it then reverted to the error:

LINK : fatal error LNK1104: cannot open file
'boost_date_time-vc90-mt-gd-1_39.lib'

And at that point I can no longer explain why that error is arising,
and have gotten tired of attempted workarounds, thus this note.

Any help getting the .lib files to show up is appreciated!

- Bob