views:

633

answers:

1

I'm building the below example boost-consuming user-mode app with the WDK, but I'm getting the following errors when linking with the boost libraries that I built earlier using bootstrap and .\bjam, from the same terminal window.

IIUC, MSDN says it's because the (hideously mangled) function - which appears to be a C++ std lib function - is marked as a DLL import, yet I have a local definition. How did this happen? Is there a way to work around this?

See also: a loosely related question.

C:\exp>more exp.cpp
#pragma warning(disable: 4512)
#include <boost/program_options.hpp>
int __cdecl main() {
  boost::program_options::options_description desc("Allowed options");
  return 0;
}

C:\exp>more sources
TARGETNAME=exp
TARGETTYPE=PROGRAM

USE_MSVCRT=1
USE_STL=1
USE_NATIVE_EH=1

MSC_WARNING_LEVEL=/W4 /WX

_NT_TARGET_VERSION= $(_NT_TARGET_VERSION_WINXP)

INCLUDES=..\boost_1_40_0

SOURCES=exp.cpp

UMTYPE=console
UMBASE=0x400000

TARGETLIBS = $(SDK_LIB_PATH)\ws2_32.lib ..\boost_1_40_0\stage\lib\libboost_program_options-vc100-mt.lib

C:\exp>build
BUILD: Compile and Link for x86
BUILD: Loading c:\winddk\7600.16385.0\build.dat...
BUILD: Computing Include file dependencies:
BUILD: Start time: Wed Oct 14 17:34:23 2009
BUILD: Examining c:\exp directory for files to compile.
   c:\exp
Invalidating OACR warning log for 'root:x86chk'
BUILD: Saving c:\winddk\7600.16385.0\build.dat...
BUILD: Compiling and Linking c:\exp directory
Configuring OACR for 'root:x86chk' - <OACR on>
_NT_TARGET_VERSION SET TO WINXP
Linking Executable - objchk_win7_x86\i386\exp.exe
1>errors in directory c:\exp
1>link : error LNK1218: warning treated as error; no output file generated
BUILD: Finish time: Wed Oct 14 17:34:44 2009
BUILD: Done

   1 executable built - 1 Warning - 1 Error

C:\exp>more *wrn
1>warnings in directory c:\exp
1>c:\exp\libboost_program_options-vc100-mt.lib(options_description.obj): warning LNK4217: locally defined symbol ??1?$basic_streambuf@DU?$char_traits@D@std@@@std@@UAE@XZ (public: virtual __thiscall std::basic_streambuf<char,struct std::char_traits<char> >::~basic_streambuf<char,struct std::char_traits<char> >(void)) imported in function "public: virtual __thiscall std::basic_stringbuf<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_stringbuf<char,struct std::char_traits<char>,class std::allocator<char> >(void)" (??1?$basic_stringbuf@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@UAE@XZ)
+1  A: 

You are explicitly including ..\boost_1_40_0\stage\lib\libboost_program_options-vc100-mt.lib in the link.

You should let the boost auto_link stuff configure do the correct #pragma comment(lib, ...) stuff ensure you bring in the right library and set the linker search path correctly. The most likely thing is that the boost library and your code are linking against different runtime libraries.

janm
Your answer helped me past this first build issue - thanks - but now the linker complains about not being able to find libboost_program_options-vc90-mt-s-1_40.lib, whereas I have only *-vc100-* files - strange, since I built boost from the exact same (Visual C 9.0) terminal window right before trying to build my app. Any ideas? Is bootstrap/bjam configuring itself to use a different VC? Any way to determine this and/or control it?
Yang
That explains why the runtime libraries are different and why you saw the error.Yes, the boost build system will examine your registry and see which compilers you have installed. If you want to build boost with msvc 9, invoke bjam with "toolset=msvc-9.0". The resultant libraries should have vc90 in their names. You can also check the boost-build documentation.If you want this to be reproducible without a command line option you can add something like: "using msvc : 9.0 ;" to user-config.jam.
janm