I have a requirement of building the boost boost_1_59_0 librabry with /md option instead of /mt.
could anybody here help me. I see there is one file build.jam where /mt is used at many places but not sure replacing /mt with /md in this file will fulfill my requirement.
/MT: b2 runtime-link=static
/MD: b2 runtime-link=shared <= The default value
You can also build all libraries, as Grigoriy suggested. In this case, the output filenames will be different. For example:
/MT: libboost_regex-vc141-mt-s-1_65.lib
/MD: libboost_regex-vc141-mt-1_65.lib
You can run b2 with the option --build-type=complete. It should build all supported variants of the libraries
OR
you can use something like this: b2 variant=release,debug link=static to build just the static version of the required library.
Related
I'm building Boost 1.72 on Windows, as part of a product build. I'm trying to build everything /MTd and, except for Boost, I've been successful. Unfortunately, though I've added "link=static" to the b2 command line, b2 insists upon building /MDd. Does anyone have any ideas on how to persuade b2 to build debug/static, rather than debug/dynamic?
I scratched my head hard but could not find someone asks the same question.
I'm building boost 1.66 with VS2017 on my machine, the command I'm using is b2 -a -j6 toolset=msvc-14.1 link=static runtime-link=static,shared address-model=64 architecture=x86 define=BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE --with-math.
I think it should use cl.exe from Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\<version>\bin\Hostx64\x64
However, from the log b2 gives me
It looks really weird to me that it's using cl.exe under arm folder to compile my address-model=64 binaries. My question is, will the binary be the same as what I expected? Could this be a bug in boost build engine, and is there a workaround to make this look right?
P.S.: I've tried editing project-config.jam to hardcode the path of desired location of compiler, but it returns me "could not locate correct compiler cl". What I referenced is: build-boost-with-msvc-14-1-vs2017-rc
is there a tool in windows SDK to ckeck what CRT a library uses?
for example I have a *.lib file, how do check if it's compiled with /MDd flag or /MT?
also how to check the same for dll or exe?
can this be done with dumpbin?
If it is a .lib file, a static link library, then you don't know anything about the CRT yet. It wasn't linked yet. You can find out about the original programmer's intention, use a hex viewer to look the .lib file, Notepad will do fine as well. You'll see the original command line that was used to compile the .obj files that were embedded in the .lib file. Simply search for "cl.exe", you'll have a good idea what compiler version was used from the path to cl.exe. And you can see the command line options so you'll know if /MD or /MT was in effect. And the /O option, important to have an idea whether you've got a Debug or Release build.
If it is a .dll file then dumpbin.exe /imports is your best choice. The dependency on the msvcrxxx.dll file will be visible, with xxx the version number like "120". If you see it then the name tells you if /MD or /MDd was used, "d" is appended for the Debug version of the CRT If it is missing then you know that /MT or /MTd was used, no hint about the build flavor available.
Following the recommendations from the library owner is always best, you can get into a lot of trouble when the CRT version or build settings of the library doesn't match yours. With non-zero odds that you have to ask him for an update, YMMV.
I'm using CMake 2.8.1 (tried this on CMake 2.8.5 too). I'm using the Visual Studio generator for VS2008. I would like to selectively apply compile flags on some some source files differently than for other files, and all of these files are going into the same static library (splitting the library into two different targets is not an option at this time). I cannot use set_target_properties in this case because the compile flags must be different. However I discovered something quite odd. The following works (works being defined that I see the /flubber option show up in the AdditionalOptions fields in the .vcproj file CMake generates):
set_property(SOURCE file1.cpp file2.cpp
PROPERTY COMPILE_FLAGS /flubber
)
But this does not work:
set_property(SOURCE file1.cpp file2.cpp
PROPERTY COMPILE_FLAGS /GR
)
Why is CMake filtering out or ignoring the /GR option? Is that a CMake bug or intentional?
Now this question is a bit contrived given that, circa VS2005, the /GR option was defined to be on by default (gives RTTI), so I really don't have to specify it. But that isn't the point because there are other flags that start with "/G" that are perfectly valid to want to specify on one source file, but not another, and in the same static library target.
Visual Studio provides special option for /GR flag:
cmake knows that and transforms your /GR flag into that option. If you open your cmake-generated project file (.vcproj) with notepad, then you can see additional RuntimeTypeInfo="TRUE" attribute inside your file configuration:
/flubber flag added:
<Tool Name="VCCLCompilerTool" AdditionalOptions="/flubber" />
/GR flag added:
<Tool Name="VCCLCompilerTool" RuntimeTypeInfo="TRUE" />
In the boost, there are two types of libs, one is ending with mt-gd, the other is ending with mt-s. What's the difference between those two?
Read Boost Getting Started on Windows
mt : multi threaded
d : Add ABI tags, could be used with:
g : using debug versions of the standard and runtime support libraries.
s : linking statically to the standard and runtime support libraries.
and more
As pointed out in the other answers and comments, these represent different configurations. With this answer, I'd like to give a more complete overview and link to the corresponding Visual Studio configurations:
Boost's -mt-s corresponds to VS' Runtime Library setting /MT
Boost's -mt-sgd corresponds to VS' Runtime Library setting /MTd
Boost's -mt corresponds to VS' Runtime Library setting /MD
Boost's -mt-gd corresponds to VS' Runtime Library setting /MDd
First and second can be built with ./b2 runtime-link=static threading=multi
Third and fourth can be built with ./b2 runtime-link=shared threading=multi