[thread] 1.33.1 with vc71, links against msvcrt and msvcprt

The goal: upgrade from boost 1.32 to 1.33.1. The gotcha: Somehow a programmer here managed to build a version of boost::thread version 1.32 whose .LIB file did not contain any directives to link against MSVCRT and MSVCPRT; there doesn't seem to be anything I do with bjam that causes version 1.33.1 to do the same. (He just handed me the .lib files to install into the right place, I knew I should have insisted he learn to do it himself. :) ) "dumpbin /directives /archivemembers libboost_thread-vc71-mt-s-1_33_1.lib" yields several Linker Directives ----------------- /DEFAULTLIB:"msvcprt" /DEFAULTLIB:"MSVCRT" commands. Which totally breaks my application (which requires the use of LIBCMT) by complaining of duplicate symbols defined in both. /NODEFAULTLIB: is not appropriate. The frustration: I can't seem to find where bjam's rules for specifying the CC Options *are*, much less know how to twiddle the Jamfile.v2 file for boost::threads. The steps I've taken: I had a similar problem with the regex library, but the vc71.mak file built perfect libraries. There's no corresponding vc71.mak file that I've found yet, for threads. So, to build threads, I basically go to the top level of boost_1_33_1 and run bjam with the vc71 toolset option. The reward: my eternal gratitude... and my sincerest thanks for help in answering this, no doubt, simple question. I've been reading the list for about a year, but don't remember seeing this specific issue discussed. Last year in http://lists.boost.org/boost-users/2005/05/11725.php was a discussion about whether boost::thread in 1.32 supported static runtime linking , and the answer appears to be yes, but like I said -- i have no idea how Junior Programmer got it done and working. Best regards, andy

Andrew Finkenstadt wrote:
Somehow a programmer here managed to build a version of boost::thread version 1.32 whose .LIB file did not contain any directives to link against MSVCRT and MSVCPRT; there doesn't seem to be anything I do with bjam that causes version 1.33.1 to do the same. (He just handed me the .lib files to install into the right place, I knew I should have insisted he learn to do it himself. :) )
While it should be possible to build a library that will not emit the autolink pragmas it is not recommended to do so.
"dumpbin /directives /archivemembers libboost_thread-vc71-mt-s-1_33_1.lib" yields several
Linker Directives ----------------- /DEFAULTLIB:"msvcprt" /DEFAULTLIB:"MSVCRT"
commands. Which totally breaks my application (which requires the use of LIBCMT) by complaining of duplicate symbols defined in both. /NODEFAULTLIB: is not appropriate.
However the dumpbin you are showing indeed is strange. The upcoming 1.34 version (from cvs) does not show this dependency, it correctly shows the LIBCMT in its requirements. As I do not currently have a 1.33 build around I cannot tell for sure if this was a bug in 1.33 or if you made a mistake during the build of the library. I will try to verify this. Roland

Roland Schwarz <roland.schwarz@chello.at> writes:
Andrew Finkenstadt wrote:
Somehow a programmer here managed to build a version of boost::thread version 1.32 whose .LIB file did not contain any directives to link against MSVCRT and MSVCPRT; there doesn't seem to be anything I do with bjam that causes version 1.33.1 to do the same. (He just handed me the .lib files to install into the right place, I knew I should have insisted he learn to do it himself. :) )
While it should be possible to build a library that will not emit the autolink pragmas it is not recommended to do so.
"dumpbin /directives /archivemembers libboost_thread-vc71-mt-s-1_33_1.lib" yields several
Linker Directives ----------------- /DEFAULTLIB:"msvcprt" /DEFAULTLIB:"MSVCRT"
commands. Which totally breaks my application (which requires the use of LIBCMT) by complaining of duplicate symbols defined in both. /NODEFAULTLIB: is not appropriate.
As I do not currently have a 1.33 build around I cannot tell for sure if this was a bug in 1.33 or if you made a mistake during the build of the library. I will try to verify this.
A correctly built libboost_thread-vc71-mt-s-1_33.lib (v1.33.0) contains only the following linker directives: Linker Directives ----------------- /DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"libcpmt" /DEFAULTLIB:"OLDNAMES" /DEFAULTLIB:"uuid.lib" /include:?id@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@2V0locale@2@A /include:?id@?$numpunct@D@std@@2V0locale@2@A Any build of the library that requires MSVCPRT and MSVCRT is just broken, since they are the single-threaded runtime, and their use indicates that the library was built without MT support. I'm surprised the library manages to build at all without MT support, since the CRT thread functions, such as beginthread, aren't available unless MT support is enabled. Certainly, the default bjam settings will build the library with MT support enabled. What did you try? I haven't tried V1.33.1, but I can't imagine it's a lot different. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

Anthony Williams wrote:
A correctly built libboost_thread-vc71-mt-s-1_33.lib (v1.33.0) contains only the following linker directives:
Linker Directives ----------------- /DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"libcpmt" /DEFAULTLIB:"OLDNAMES" /DEFAULTLIB:"uuid.lib" /include:?id@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@2V0locale@2@A /include:?id@?$numpunct@D@std@@2V0locale@2@A
...
I haven't tried V1.33.1, but I can't imagine it's a lot different.
I can assure this. I just built the 1.33.1 version. The only linker directives relevant to runtime lib linking for the libboost_thread-vc71-mt-s-1_33_1.lib are indeed: /DEFAULTLIB: "libcpmt" ... the static multithreaded C++ runtime /DEFAULTLIB: "LIBCMT" ... the static multithreaded C runtime I cannot imagine how it should be possible to build the library with the multithreaded requirement missing. In my opinion this should not be possible without modifying the source before compiling the library. The best advice I can give, is to start over with a fresh download and compile of the library. Roland

Anthony Williams wrote:(Regarding libboost_thread-vc71-mt-s-1_33.lib (v1.33.0)).
Any build of the library that requires MSVCPRT and MSVCRT is just broken, since they are the single-threaded runtime, and their use indicates that the library was built without MT support. I'm surprised the library manages to
Nope, MSVCPRT and MSCRT are "multi-threaded" runtimes, but they do not imply static linkage (which means --> LIBCMT) .. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/... Cheers Amanjit Gill
participants (4)
-
Amanjit Gill
-
Andrew Finkenstadt
-
Anthony Williams
-
Roland Schwarz