I compiled and ran bjam and even b2.exe with the following command:
bjam --with-system --with-thread ..etc
I got my library files as:
libboost_system-vc110-mt-1_53.lib
libboost_system-vc110-mt-gd-1_53.lib
The problem is that, once I stated the directory and linked them in my project it keeps saying Version Mismatch: found /MDRelease in project /MTRelease.
Yes my project is statically linked for /MT release and that's what I need but boost is causing me trouble.
Any ideas? Thank you.
This sounds like a version problem. The error that you are getting indicates that some components were built with one set of libraries, and other components were built with a different set of libraries.
If you are building other components that uses this code with a different type of library, for example MT (multi-threaded - no debug), or MDd (multi-threaded debug for a dll) then you might get this error. You could also get this error if you are linking with the wrong set of libraries for Boost. You need to build with the same type of libraries that you are using in your own code. If you are using MTD, then build with the MTD version of Boost libraries as well.
To see what libraries your project(s) are using, right click on the project in the Solution Explorer Window and select properties. Properties can also be selected from the project menu, but make sure that you have a file in that project as the current file open in the editing window before doing this. Under Runtime Library you will see the type of library that you are using. If the project type is a dll, then this value should really be set to MDd. To see what type of project it is, click the Linker (or Librarian) option under properties and if the output file is dll, then the project type is dll. If it says library or exe, then the project is library or exe respectively. All of your projects of a given type should be built the same way. You should not try to mix and match release and debug versions for example. If you have an exe that you are building, then use whatever library that was used to build the library type of projects. To set the library, under properties select Configuration Properties / C/C++ / Code Generation / Runtime Library and choose a type from the dropdown box.
If the configuration looks correct for all projects, then try rebuilding from scratch. This can be done by right clicking on the project and selecting clean, followed by selecting rebuild.
When running b2.exe to build the libs, I always use the -q option to make it stop if it encounters an error. If there are errors in the build, they can sometimes be difficult to see since there is quite a bit of output from b2. For a list of options associated with b2, see this link.
Note also that the file libboost_system-vc110-mt-1_53.lib can only be used for VS 2012 projects. If you are not using VS 2012, then you need to do two things. First, you might not be able to use boost version 1.53 or higher with any version of Visual Studio prior to 2012 since 2012 is the first version that best supports the latest version of the C++ standard. So, you would probably have to use 1.52 instead. The second thing you would have to do is specify in b2 the version of Visual Studio that you are using with the toolset option (for example - --toolset=msvc-10.0 - if using VS 2010) so that it will build the correct libraries for you.
You need to build static libs. This will do the trick:
bjam --build-type=complete
Related
I have an SFML, Visual Studio project that needs to be linked using the /MT option in the runtime library settings because I want to avoid having to install the microsoft redistributable to every computer that runs the program.
When I added sfml to the project, it appeared to work fine in its dynamic form. However, when I tried the program on another computer, it told me that I had missing visual studio dlls.
I understand that in order to link sfml statically to the project I would have to rebuild it with different runtime libraries. My question is why would it be able to correctly compile with sfml dynamically linked to the project and have the project set to /MT at the same time if it failed to statically link the necessary visual studio dlls to the project?
After discussions in the comments, we agreed on this:
It is not uncommon to link some libraries statically and still link dynamically to others, like the language runtime. So the compiler should not complain about this.
To get a single executable containing everything, the program must link all libraries statically and they must, in turn, also link statically to all their dependencies.
Otherwise, if we have one dynamic library, like SFML, that library will likely in turn link dynamically to the runtime library. And that will still require the runtime DLLs.
This is possible, you'll just have to build SFML yourself (which isn't that hard to do).
Just make sure that you set the CMake variable SFML_USE_STATIC_STD_LIBS to TRUE so SFML uses the static runtime, no matter whether you're actually creating static or shared libraries.
In short:
Clone the official repository.
Install CMake. (If you're using Visual Studio 2017, you can also directly open the source directory as a Folder, but setting the variables is a bit more tricky this way.)
Create a build directory, go there and run CMake: cmake -DSFML_USE_STATIC_STD_LIBS=TRUE -DCMAKE_INSTALL_PREFIX=C:/path/where/to/install/SFML C:/path/to/the/cloned/source/repository
Once done you'll find a Visual Studio solution and projects.
Just build the INSTALL project for the Debug/Release targets and you'll get your shared SFML using the static runtime.
The process is extremely non obvious and error prone so I think a place where a proper procedure is described is required.
I will answer my own question below, but it is more or less a hack and slash solution as Visual Studio is mostly Terra Incognita for me and I just stumbled on a combination that works after a lot of trial and error, sometimes not even understanding what I am doing. If it looks horrible - sorry about that. There was simply no proper guide for me to use.
Steps:
Download GRPC and Protobuf3 from their respective github repositories.
It is better to use GRPC from repository than from zip package because this way you will be able to populate "third_party" folder via git.
Download CMake/CMake-gui and feed protobuf\cmake folder to it. This will generate your visual stuido projects
Compile All_Build.vcxproj as is in release mode. This will generate protoc.exe file which you must store somewhere.
Here comes the trickery:
By default, Release protobuf/grpc projects are compiled as /MT.
Chances are - qtcreator is compiling your projects as /MD.
If you try to use the library generated by MSVC as is - you will get a library format conflict.
So first step is to edit libprotobuf subproject:
C/C++->Code Generation->Runtime Library to Multi-threaded DLL (/MD)
Next problem: default project will generate a .lib file, that even with /MD I have been unable to succesfully attach.
If anyone knows how to avoid a lot of "undefined reference" errors while trying to use it, feel free to comment below.
// these are only necessary if you can't link statically as I do
Configuration Properties->General->Target extension : .dll
Configuration Properties->General->Configuration Type : Dynamic Library
We also have to add a bunch of defines:
Configuration Properties->C/C++->Preprocessor : add PROTOBUF_USE_DLLS;LIBPROTOBUF_EXPORTS
Now you can compile protobuf. Do this and store libprotobuf.lib and libprotobuf.dll somewhere
Onwards to grpc.
Open grpc.sln
As I am not using MSVC for my work routinely these later steps were non-obvious.
You will need Nuget installed in Visual Studio before anything else.
Nuget will, on compilation, pull a bunch of dependencies into your grpc\vsprojects\packages folder.You will need .dll's from there later if you plan to deploy your app.
Once it's installed go and switch /MT /MTd to /MD /MDd depending on the mode you plan to use, the same as for protobuf.
/MD corresponds to Release build (for me) while /MDd is for Debug
Also, you need to remove "z" and "borinssl" subprojects as they are broken on windows and won't let you compile properly.
Compile the project. It will produce grpc.lib grpc_unsecure.lib grpc++.lib grpc++_unsecure.lib which you will need to store somewhere accessible to qtcreator while it builds your project (same with libprotobuf.lib and libprotobuf.dll)
Open grpc_protoc_plugins.sln
Add a folder that has libprotobuf.lib to Library Directories in project configuration.
Compile grpc_cpp_plugin. It will produce grpc_cpp_plugin.exe which you need to store with protoc.exe
If you plan to deploy your app you will need to copy a bunch of dependencies nuget collected for you from packages folders:
libeay32.dll
ssleay32.dll
zlib.dll
When i use Visual Studio, my executables depends on microsoft redistributable package - the package that deploys MS's runtime DLLs. That is annoying to me. What disatwantages my executable would have if i would use MinGW?
I also want to try link with lib- avcodec/avformat, that are built by MinGW and i have no my own mind power to build them in VS from src.
In case of using MinGW you will depend on DLLs that are shipped with mingw. It is not big deal to change one vendor to another.
If you already have MS project, review possibility to statically link MS libraries (it is option is provided for some of VisualStudio projects on creation time in project options)
You can link everything statically with MinGW. Use the -static linker flag.
No need for redistributing any DLL's, but you have to make sure that in the c++, there's no exceptions being passed over DLL boundaries (so make sure every C++ library is linked statically in this case).
I have a simple C++ program. I want to just build the exe and give it to a person on another complete non-development box. Is there a way to build such a simple, single-source file to an executable in Visual Studio without needing all the crap ? I have changed the program to compile in MT mode, instead of MTD which statically linked the msvcr.dll file, but now it is looking for msvcp.dll file. How can I compile so that my executable either 1) doesnt include all this junk or 2) statically links it all so that I have exactly one file to transfer to another Windows PC to run
Thanks
If compiling with /MT is requiring msvcr100.dll, something included in your application is probably trying to link with it, possibly a third party component. I would check any third party libraries and related.
MSVCP100.DLL is the C++ standard library. You might want to double check that it's not looking for MSVCP100D.DLL, which is the debug version; mixing release and debug mode libraries could cause this.
MSVCRT100.DLL is the C run-time library, and MSVCP100.DLL is the C++ standard library. Both should go away if you build with /MT, in that case static versions of these libraries should have been used.
My guess is that you either did not fully rebuild your app after switching to /MT, or that one or more files in your project have custom settings that include /MD. You may want to open the properties dialog box on the page that shows the /MT and then click on all your source files one by one to verify that none of them still show /MD.
I have created a wn32 project with Visual Studio 2008 and Visual C++ language, it uses the ws2_32.lib library and then I compiled in Release mode.
It runs very good in the same computer, but when I copy the exe file to other computer (that doesn't have installed Visual Studio), it doesn't run.
The message I see is:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
But, if I compile my application using DEV C++, it generates a bigger executable (738KB) compared with the Visual Studio 2008 executable (9.5 KB). However, the DEV C++ executable runs in the other computer.
I have add the library ws2_32.lib to the linker properties of my project, in the Additional Dependencies field.
How can I fix it to work with Visual Studio 2008?
My code is the following: http://www.stan.com.mx/yupi/udpserver.cpp
The problem is almost certainly that the other computer does not have version 9 of the C++ CRT installed.
The default setting for compiling against the CRT in VS2008 is to dynamically link vs. statically linking. If you want to deploy your program with a real setup project you'll need to include the CRT redistributable.
However if you want to do an XCOPY deployment follow the steps on the following page.
http://msdn.microsoft.com/en-us/library/ms235291.aspx
Try installing the Visual C++ redistributables. If that doesn't work, use DependencyWalker to find out what DLLs are missing.
I agree with JaredPar. The application you build with VS2008 is using dynamic linking, whereas the DEV C++ is linking statically, hence the larger size and why one works and not the other.
However, if its a plain win32 application project you've got (and you don't want/need to distribute it with a setup), you may be able to get it to run on another machine without redistributing the CRT by getting VS2008 to link statically for you (if its just the standard lib you're missing). I don't have a copy of VS2008 to hand, so I'll describe how to do it in VS2005 and hopefully it'll translate across.
Bring up configuration properties for the project (right click the project name, then select "properties" from the menu)
Expand "Configuration Properties", then "C/C++", then click "Code Generation"
Under the "Runtime Library" item, for your particular configuration select the non-DLL version of the library i.e. for debug builds you want "Multi-threaded Debug (/MTd) and for release builds you want "Multi-threaded (/MT)"
Try and see if that works. You'll obviously get a much bigger final binary now the library is statically linked.
You may be missing an external dependency required by your program. Check the project settings to see if you are linking against MFC dynamically for example. You can also run Depends utility to check for missing dependencies.