I have C++ source code (xyz.cpp) for static library called libxyz.lib, in this xyz.cpp I call some functions p, q, r which are part of other static library called libabc.lib.
Now when I compile code (xyz.cpp) i want that object code for libabc.lib gets included inside (libxyz.lib)
Is this possible?
Or do I have to ship both libxyz.lib & libabc.lib to user who wants to use them ?
I am using Visual Studio C++ 2005
Thank you in advance
AFAIK you can only achieve that by turning xyz into a DLL, but in that case you would still be shipping xyz.dll + a xyz.lib file + required headers. When you build a static lib, other static libraries are not linked in: the .lib file only contains the object code of xyz functions. See http://msdn.microsoft.com/en-us/library/ms235627(v=vs.80).aspx
If building from the command line, you must build the program in two steps. First, compile the code using Cl.exe with the /c compiler option (cl /c /EHsc MathFuncsLib.cpp). This will create an object file named MathFuncsLib.obj. For more information, see /c (Compile Without Linking). Second, link the code using the Library Manager Lib.exe (lib MathFuncsLib.obj). This will create the static library MathFuncsLib.lib. For more information on the Library Manager, see LIB Reference.
Related
I have some DLLs that I want to use in a FORTRAN Project in VISUAL STUDIO but I can't find how.
Here is a simple code I'm using to find out how.
Using visual studio I created a DLL from this
subroutine printing
!DEC$ ATTRIBUTES DLLEXPORT::printing
print*,"dll naimi created"
end subroutine printing
I added the link of the DLL to project>properties>Linker>General>Additional Library directories
Main program:
program Console11
implicit none
call printing
end program Console11
ERROR : Error 1 error LNK2019: unresolved external symbol _PRINTING referenced in function _MAIN__.
other solutions related to this suggest using the .lib created while generating the DLL, but in my real case I only have the DLLs without their .lib.
So how to use a DLL ... ?
You appear to be trying to use a DLL as an input file to the linker.
(You also appear to be trying to specify a file for a linker option that takes a directory. To specify an additional input file for the linker, either add the file to the project just like you would attach a source file, or use the "Linker > Input > Additional dependencies" project property. The property you mention in your post then tells the linker where (which directories) to search for those additional dependencies.)
Unlike the unix convention, you do not link against DLLs when building executables and other DLLs on Windows. The DLL typically does not contain the necessary information for the linker - instead that information is contained in an import library (which is just a variation of a typical .lib static library) or equivalent.
If you were able to successfully build a DLL, then you will probably find the import library for that DLL in the same directory as the DLL. Supply that import library as an additional dependency for projects that require the DLL.
When you link an EXE or other DLL using an import library on Windows, the target DLL is automatically loaded by the operating system when your executable code is loaded. This is called load time dynamic linking.
If you do not have the import library for a DLL, then your choices are:
Ask the person who built the DLL for the import library.
Reference the DLL using run time dynamic linking, rather than load time. This means that you use the Windows API functions LoadLibrary, GetProcAddress and friends in your program to explicitly tell the operating system to load a particular DLL and to obtain the address of a function pointer. If you are using Intel Fortran, then complete examples of this are installed with the compiler - see in the file "C:\Program Files (x86)\IntelSWTools\samples_2016\en\compiler_f\psxe\DLL.zip" or similar.
Generate an import library from the minimum information in the DLL, plus other information about the DLL that you may have. One approach to this is to write a module definition file (.def) for the DLL, and then use the LIB utility to turn that def file into an import library. See How to make a .lib file when have a .dll file and a header file for an example.
My solution contains several c# projects.
It's easy to add "refernce" from one project to another(References-Add Reference-Project). After that I can use classes from referenced project.
How can I do the same for native c++ projects? What kind of projects should I create? Console application/DLL/Static library?
There are two things in C / C++ :
Headers file, that will tell your program what they can use (e.g. class, function prototype declaration)
Implementation, either as a
source code that you recompile with your program
static lib (.lib on windows)
dynamic lib (.dll on windows)
You need both to compile your program with parts from another project.
If you only need a class from a big library and you have the source of this library it may be easier to reference the file corresponding to this class (and its dependencies of course). But if you need more, you should add the other project's directory to the include path of your current project in VCC, and link against the library (either static or dynamic, according to your needs).
I need to create a static library which will use winsocks.
As you already know in order to use winsocks you need to reference the ws2_32.lib in your project, anyway from visual studio I can't find the "link" tab in which I would usually do that.
If I open another project, a project who is not a library (say a win32 console application) this tab is present...anyway seem strange to me that I can't build a .lib file which, in turn, includes another...I don't think to be the first one who needs to use sockets in a library..or not?
Solved compiling by command line...
cl myLib.c /link ws2_32.dll
I've got a 3d party static library built with some older version of MSVC, and I successfully link it to my application in MSVC10 (VisualStudio2010). Now I upgraded to MSVC11, and I'm unable to link it:
2>LINK : fatal error C1047: The object or library file 'MyLib.lib' was
created with an older compiler than other objects; rebuild old objects
and libraries
I guess this happens because the lib was compiled with /GL option, so the object files don't really contain COFF, but some intermediate format.
I don't have the library source-code to re-compile, and I don't want to make a dll out of it to link dynamically.
Is there a way - maybe some undocumented trick - to "re-compile" these obj's to COFF and eventually link them to MSVC11 application?
Even if this was possible, you don't want to do this: linking object files that are built against different versions of the CRT usually ends in tears. More specifically, if two such object files both use the C++ Standard Library, it is all but certain that you will violate the One Definition Rule (ODR).
If you cannot rebuild the module using Visual C++ 2012, then you should encapsulate it within a dynamic library, built with Visual C++ 2010, and avoid using any C++ Standard Library types in the interface of that DLL.
I'm new to vc++. I've just built a software and it generated a .dll and a .lib. I need to use functions from this in my code. Do I need to link to both .lib and .dll to build my code? What project properties do I have to alter to do this linking?
Actually, you need only the .dll file. It contains all the necessary code and data to run it's functions. It also contains a table that links the symbolic names of the functions (e.g. the function PrintMe), their ordinals (the number of that function in the DLL) and their addresses in the DLL.
If you want to use only the DLL, you have to "manually" get the symbols resolved:
Let's say you want to use the function PrintMe of the DLL. What you had to do is to resolve it's name (PrintMe) or it's ordinal (PrintMe is the 1st function of the DLL) to it's address. For this, you could use LoadLibrary, GetModuleHandle and GetProcAdress from the Win32 API (aka Windows SDK). Additionally, this method allows you to load the DLL at runtime (see below).
The easier way is to use the MSVC(++) features __declspec(dllexport) and __declspec(dllimport), e.g.
// your DLL
__declspec(dllexport) void PrintMe()
{
printf("Hello World!");
}
// you project to use the DLL
__declspec(dllimport) void PrintMe();
The first one (dllexport) tells the compiler to export the function. The second one (dllimport) is the interesting one: It creates all the necessary code to be able to use the function from the DLL.
For this, you need the .lib file in your project (which wants to use the DLL). The .lib file contains information for the linker to resolve the symbol name (PrintMe) to its address in the DLL. Since the .lib is statically bound, the linker can make use of it - the DLL on the contrary is bound at runtime / loading time, so the linker cannot use it. (Yes, the information in the .lib file is redundant.). Note: You cannot change the whole DLL when using this method w/o rebuilding your project with the new .lib file. Some structure changes affect the addresses of the functions in the DLL, see this SO answer.
One last difference between using the Win32 API (LoadLibrary...) and the MSVC method via __declspec is the loading of the DLL. When you use LoadLibrary, the DLL is loaded at runtime, of course (so you can catch exceptions when it cannot be found and so on). The other method loads the DLL at loading time, so you program will terminate (will not run) when Windows cannot find the DLL.
When you create a project in VS, you can activate the "export symbols" checkbox at the end of a wizard (Win32 project). That gives you some examples of exported symbols. Additionally, it introduces a macro plus a preprocessor defition plus some directives that are very useful:
// DLL header
#ifdef _YOUR_DLL_EXPORTS
#define YOUR_DLL_API __declspec(dllexport)
#else
#define YOUR_DLL_API __declspec(dllimport)
#endif
YOUR_DLL_API PrintMe();
You now can use this header file to build you DLL as your DLL project has that _YOUR_DLL_EXPORTS definition (see project properties page, C++, preprocessor). The project that uses the DLL can use this header, too, but then must not have such a name defined. When you include the header file in the project in which you want to use the DLL, the macro is resolved to __declspec(dllimport). This instructs the linker to look for this function (which is found in the .lib file) and create all the necessary code to load the DLL at runtime and resolve the symbol name.