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.
Related
My question is as the topic.
I am currently using Mingw32 compiler in Qt creator to compile my application. The problem is that I include a .lib static library and header file which compiled from Visual Studio 2017 in my application.
When I further run or compiled my application in Qt. I would be facing the error code, unrecognized file format pointing to the .lib file.
I reasonably doubt that: For example, I can not use compiler 1 to compile other libraries compiled from compiler 2.
I follow the instruction here:libwdi Installation and Compilation to compile the "libwdi.lib" file.
FYI, the reason that I use Visual Studio to compile the .lib library(libWdi) is because it's easier to achieve on my Windows OS after I tried using wingw32-make from Qt5 Tool. It is such a pain since I can not even run ./autogen.sh to generate the makefile for Mingw32 on Windows.
Appreciate any step-by-step information on how to build a workable .lib file for Qt creator, including using VS, mingw, and cross-compilers.
If the target library uses c++ features in its public interface then it is likely this is not going to work regardless of what machinations you go through. Even different versions of the same compiler often have problems in that situation.
Pure C on the other hand will usually work (on Windows non-MS tool sets will be made to at least consume the MS intermediate object format, even if not used by the compiler/linker normally).
I've knowledge of C++ and compiling small plug-ins (always based on a similar and laid out workflow). Though currently I need to compile the latest version of FFTW into a static library (or get it from the compiled version which should supposedly be a lot easier) and it's giving me an insanely hard time. Probably because I don't know the ins and outs of compiling. As a note I'm working on Windows with Visual Studio.
Since I really want to know how this should work I'm asking the question here.
Basically I need a static .lib of fftw3f library on Windows that I can include in another Visual Studio project.
The first I did was download the 64 bit dll's of FFTW from the website (hoping I could use this).
http://www.fftw.org/install/windows.html
Then I've done the accompanying step they stated, that is:
Run the following in lib.exe.
lib /def:libfftw3-3.def
lib /def:libfftw3f-3.def
lib /def:libfftw3l-3.def
I've done this as well and got a .lib file that I could use in my project correctly. I've been able to compile my project, yet the output build apparently dynamically linked to the library instead of including it as a static library.
I'm compiling my project to .dll but require the fftw3f library to be statically included in my output.
Using lib.exe /list libfftw3f-3.lib I was able to find out that the lib file was referencing the libfftw3f-3.dll.
According to my google results this would mean the .lib file that I created is a DLL import library instead of static library.
It's hard to figure out how to phrase my question because I'm not sure what the terminology is and what's going on behind the scenes. I guess:
How can I use the libfftw3f-3.lib file created from lib.exe as a static library in my own project. So that it is included in my output .dll instead of dynamically linked?
Based on what I learn from comments/answers I'll be happy to update/edit/rephrase my question to make more sense for most other users as I'm likely way of with the terminology
You cannot expect to convert a DLL into a static library.
In order to create a static library you need to re-compile the library from its source code, with an output target that is a static library. If you cannot obtain the source code, then your goal cannot be achieved.
I'm working on a C++ solution in Visual Studio 2010. I've a DLL file which is using some standard C++ library functions (such as string or file functions). For some portability reasons I have to compile this DLL with /MT option, so all required runtime library functions will be linked to the released DLL file.
I've another C++ project which is a windows application, this project also compiles with /MT option and generates an standalone exe file. The second project also uses the same standard C++ library functions that are already linked in my DLL (The executable also uses some DLL exported methods).
Now here is my question: Is there any way to tell linker that don't link common runtime functions which already linked to DLL file & don't link these shared parts again in the exe file (e.g. reuse same code for string functions which already linked to my DLL)?
No, you can't do that. Although executable depends on DLL, they can still be considered as separate and stand-alone binary artifacts, each of which should contain required symbols for proper execution.
This is one of the reasons why dynamic linking is preferred. Furthermore, I don't see any problem to link dynamically and redistribute the runtime with your application.
Although Microsoft Visual C Runtime is included on most platforms, there are many different versions of it, some of which are buggy or/and break backward compatibility. Thus, it is always a good idea to distribute the version of msvcr*.dll that you know works for sure with your application.
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.
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...