Like the msvcr70/msvcr80/msvcr90.dll, what's the code like to instruct the linker to link to one of them dynamically?
Or has that anything to do with c/c++,but cmake?
The specific examples you give happen to be DLLs that are usually linked through manifests and the side-by-side, at least when building applications (with the correct project settings) from Visual Studio. Why are you trying to instruct the compiler to link them by code?
The most often-used way to link to a particular DLL is when you have the lib for the DLL available, and then to use the pragma
#pragma comment(lib, "<library name>")
You specify a .lib file when you link, and the matching .dll will be used at run time, so (for example) if you want to use msvcr70.dll, you'll want to link with msvcr70.lib.
In general, the C/C++ runtime you link against is dependent to the version of VisualStudio you are using. (msvcr80.dll -> VS2005, msvcr90.dll -> VS2008 etc.)
Some deeper insight on how this works and some tricks to work araoud this you can read up in this blog post.
eh, surely you want to first understand DLLs/linking... http://www.infernodevelopment.com/how-create-dll-c-using-run-time-dynamic-linking
the question as written is not answerable
Note: not sure what you mean with Cmake, but you can easily specify link libraries in your CMakeLists.txt file... the exception being the DLLs you note, because they are platform-dependent. You'd need something in the CMake script to check versions of MSVC.
Why would you want to link to an older run-time though, Vista onward come with the VC9 run-time, and if someone is using XP you can just give them the 'redistributable package' for VS2008/2010...
Related
Right now I'm trying to create my first "real" project in C++ using Visual Studio 2019. I need to include a third-party library as a dependency. The instructions on the project homepage simply recommend to include all source/header files directly into the project. My understanding is that it's a bad practice, since the end result would look quite ugly in any VCS.
Thankfully, the library author also provided build scripts that call cl, lib and link with appropriate arguments and produce the coveted foo.lib. I added that file to dependencies in linker options and after some haranguing with compiler/linker options finally got it running.
To my distress, I realised that I've done all those manipulations in Release configuration, which prevented me from using the debugger. I then built the library with /MDd, fixed some compiler options... and got a bizarre compile-time error in vcruntime.h ( fatal error C1189: #error: _HAS_CXX17 and _HAS_CXX20 must both be defined, and _HAS_CXX20 must imply _HAS_CXX17).
At this point, I knew I was doing something terribly wrong, since including a simple library should't require so much manual knob-tweaking. What is the right, canonical way of including third-party dependencies in Visual Studio (and C++ in general)? Assuming the dependency isn't available on Nuget, vcpkg or somesuch.
As I understand from the stuff you did was on Windows. First of all I would recommend you try a linux distro. In windows it is possible to get lib files running, but not easy. It would help if you could send me a link to the library you are using.
The usual approach is to just stick those sources in their own directory and their own Visual Studio project (not solution). This can still build a foo.lib. You won't need many options for this.
Next, you just tell Visual Studio that your own project depends on that other project, and it will then link foo.LIB for you.
Having said that, it sounds like you try to build your two projects with different settings for the C++ version. VS2019 has good support for C++17 and experimental support for C++20, so you can choose. But you need to choose consistently for all your projects.
In larger solutions you can us a .vsprops file for that, which is like an #include for project files. A bit overkill when you have two projects, a lifesaver when you have 150.
It varies a bit how you include 3rd party libraries, sometimes 3rd party libraries have an installation and install themselves like under Common Components sometimes you have to do it manually.
E.g. YourSolution/3rdParty/foo/include
YourSolution/3rdParty/foo/lib
YourSolution/3rdParty/foo/lib/release
YourSolution/3rdParty/foo/lib/debug
Sometimes the libraries have different names then they may be in the same folder.
Once you have that structure go to your project's properties C/C++ and add the include under Additional Include Directories make sure you have configuration "All Configurations" here. Then go to Project properties/Linker/Input and the dependency for Debug Configuration and for the Release Configuration - since usually they are different libraries per configuration. e.g. release/foo.lib and debug/foo.lib (foo.lib foo-d.lib or whatever they are called).
Use the macros to make sure you get the right locations so that they are relative to your solution and project. It is not good having absolute paths. E.g. $(SolutionDir)3rdparty\foo\include
Disclaimer : I am not sure this is the "optimal" way to do it but that is the way I do it.
I make use of a vendor supplied library in a C++ program. All the vendor supplies is a .lib, .dll and the header files.
This library was first used in MSVC++ 6 and now in MSVC 2010.
It appears they support mingw, qt, etc. I have had no problems with using it in either debug or release mode.
I have recently added another dependency to the project, yaml-cpp, an open-source project that provides no binaries. I am able to build yaml-cpp using cmake and MSVC 2010 as a static library and can link it to my project successfully.
In order to do this I must link to the debug and release versions of the .lib respectively as I have run in to weird Microsoft CRT/linker issues I am just learning about.
I am curious, how does the vendor of my first library (libXl if you are curious) provide a .lib and .dll that works on a range of compilers without worrying about the CRT version?
How do you write code that allows this or is it the linking process? yaml-cpp is a cross platform library, is it possible for me to compile it in a similar way that would allow me to use a single .lib within my project?
I am not sure what resources to look for to learn more about it. How do people learn about this kind of stuff? Thanks!
The reason that a .lib and dll can work with a variety of compilers is down to ensuring that there are no compiler-specific dependencies in your code. .lib and .dll are not recompiled so once they are made they should be stand-alone if so coded, and their functionality can be accessed from anywhere with the ability to use a .dll or a .lib.
There is some discussion on the pros and cons of dll and lib here which you may find interesting.
Let me know if you need more info and I will do my best to oblige.
I am using Visual Studio 2005 to build a DLL. By opening the DLL in a text editor I can see that it refers to multiple MS CRTs as follows. How can I find the name of DLL which the dependency elements refer to? I am trying to specifically find the source of the dependency which links to the 8.0.50727.5592 version of the CTR, it is the last one.
Any ideas?
Most likely, you're getting the dependency injected automatically because you're linking against a 3rd party library that uses a different version of the runtime that you're using. Check the libraries against which your dll links and most likely one of them will have the exact extra dependency that you have there. By the way, you can use VS2005 to open a dll and look at its embedded manifest.
I know it's an old post but I had the same issue and found a great tool to list all dependencies for any included libs. I use VS 2010:
In command prompt, go to Microsoft Visual Studio 10.0\VC\bin and run command:
link /dump /directives libpathandname.lib
This will list out all linker dependencies including exact CRT versions.
I'm not sure whether it will tell you exactly what you need in this instance, but Dependency Walker may shed some light on it. It'll show which of the dependent dlls depend on the CRT and it may show the versions from the manifests, though I'm not sure.
I got a VS10 project. I want to build some C++ code so I can use it in python. I followed the boost tutorial and got it working. However VS keeps to link boost-python-vc100-mt-gd-1_44.lib but it's just a wrapper which calls boost-python-vc100-mt-gd-1_44.dll. That's why I need to copy the .dll with my .dll(.pyd) file. So I want to link boost:python statically to that .dll(.pyd) file. But I just can't find any configuration option in VS or in the compiler and linker manual. The weirdest thing is I've got one older project using boost::filesystem with the very same config but that project links against libboost-filesystem-*.lib which is static lib so it's ok. I've been googling for couple of hours without any success and it drivers me crazy.
Thanks for any help or suggestion.
You probably don't want to do that. Statically linked Boost python has a number of problems and quirks when there are more then one boost python based library imported. "But I only have one" you say. Can you guarantee that your users won't have another? That you might want to use another in the future? Stick with the DLL. Distributing another DLL is really not that big a deal. Just put it side-by-side in the same directory.
What libraries are linked depends on the settings of your project. There are two possibilities: You can build against
statically
dynamically
linked versions of the c-runtime libs. Depending on which option is selected, the boost sends a proper #pragma to the linker. These options need to be set consistently in all projects which constitute your program. So go to "properties -> c++ -> code generation" (or similar, I am just guessing, don't have VS up and running right now) and be sure that the right option is set (consistently). Of course, you must have compiled boost libraries in required format before...
I use MSVS 2010 and MSVC++E 2010 to build my applications in C++ and I've notice a lot of my friends (who test my apps on their PCs) don't have the Microsoft C++ runtime library installed on their computers. I've started including the Microsoft C++ redistributable package with my apps, but this seems unnecessary. Would I be able to instead include the libraries in my executable directory? I know that one of the libraries used is msvcr100.dll, but are there also others I need to include? Or is the redistro my best option?
in your project options, for code generation, you can choose the STATICally linked libraries instead of the DLL versions. That eliminates the need for an external dependency like this, at the cost of a larger EXE.
You don't necessarily need to HAVE to have the runtime library within your executable directory, you may use a Manifest File that has a relative path which points to runtime if you wish. But yes, you can include the libraries within the install of your application.
I think we lug around the msvcr as well as the msvcrt and the msvcp DLLs which now that I'm writing that out, might be a bit overkill.
When you build your application to a static runtime, you don't need to distribute the runtime dlls.
Otherwise you have to include the Microsoft runtime.
Links to runtime installers for Visual Studio 2010
Compiling your project with /MT solves the distribution problem. Be careful though, it can get you in trouble when you use DLLs. They will have their own memory allocator. If they export a function that exposes a pointer or a C++ object that needs to be released by the client code then you'll have a very hard to diagnose memory leak on your hands. Very easy to do, just return an std::string for example.
Anyhoo, the setting is found by right-clicking the project in the Solution Explorer window, Properties, C/C++, Code generation, Runtime Library setting.
Also note that VS2010 supports local deployment. Just put the msvcr100.dll file in the same directory as your EXE. You also need msvcp100.dll if you use STL or iostreams.