I'm tryng to figure out how to use a module of a DLL library in a fortran project,
still don't know how.
When I read different discussions concerning this, they all talk about using the .lib generated when the DLL was built,
Isn't a DLL a Library (like a .lib) but shared.
why do we need the .lib ?
Related
I got a project that uses Cmake and has a configuration to create a shared library. This project has some external dependencies (like zlib, etc). Generating shared library and linking against it would require not only providing dll generated by the project, but also dlls for all dependancies (since the library itself is linked against other libraries).
I'm wondering if it's possible to create a single dll of that project, that would have statically linked all dependencies into it. I tried creating an OBJECT library and using it to create a SHARED library with Cmake, but had no luck with this approach. Is this can be achieved?
Unfortunately static linking of the whole library is not an option due to licensing issues and I'd like to avoid attaching 10 dlls to the application package. I need that only for Windows.
I am building a Visual C++ 6.0 workspace in Visual Studio 2010, so that it'll update some dependencies
I have all the files and dll's it is looking for, it builds but then fails at linking with this error
1>LINK : fatal error LNK1181: cannot open input file '\Projects\exe\CRelease/api.lib'
I have api.dll which it needs to build, but I don't have a .lib file version of it. and even if I did (like if I somehow converted the .dll into a .lib), I wouldn't know where to place it in a directory structure
how do I "fix" this?
guidance appreciated, thank you
Normally api.dll would have an accompanying import library called api.lib which is what you need to link to. The import library is different to a statically-compiled version of api (which would also likely be called api.lib) - it's more like a list of available functions provided by the dll, and so will usually be much smaller than a corresponding static library.
If you do find or get api.lib, it doesn't really matter where it lives, as long as it can be accessed by your linker.
If you don't find the import library, you're looking at doing explicit run-time linking where api.dll is loaded and unloaded explicitly in your code, and api's exported functions are called through function pointers.
These days, I use Flex & Bison generated some codes to develop a SQL-parser alike tools, these code can't compiled silently(may be this another topic) in VS2005,but GCC/G++ works well, then I compiled these code with mingw in dll(in windows xp), and then linked these function facades in VS2005, but it seems can't link the dll during linking.
Does MS VS2005 recognize the dll which compiled using mingw on windows? Is there anything I need to do additional? For example, adding something in the include-file that declare the exported APIs?
Does any one can give some advices?
The condition is, as in VS2005, if you want to export some APIs, you may show a *.def file to tell nmake which API you want to export, and then you may create a(or some) *.h file to declare somthing about these APIs(adding some stdcall alike prefix as a call protocal) and some data-type definition. But with GCC/G++, you do not need to do such boring things, just use [ar], you can get these APIs, so my *.h file do not add call protocol and no *.def, just like common function declaration. After *.dll generated, add the *.h file and [mv] generated *.dll in VS2005 project directory, then set the linking *.dll in project setting. Does these steps generated my Question?
BTW, I found and tested VC6-compiled dll can be linked with mingw in Windows XP, but the reverse can't work.
Anyway, forgive my poor English, and thanks for your concern.
VS2005 does not recognize any DLL to compile anything, and I doubt mingw does.
When your application shall use a DLL, you need to tell VS2005 what functions are provided by the DLL.
Load Time Binding
The entry points are defined in the EXPORT directory of the DLL. The content of the EXPORT directory can be defined with the DEF file, while compiling the DLL. Theses exports can also defined using the #pragma __declspec(dllexport) directive. When you compile the DLL the linker will also generate a *.LIB file for the consuming application. This LIB is called import library.
The signatures of the exported functions must be provided by function prototypes, usually in a *.h file.
When you compile your application with load time binding, you include the *.h file in your source code and add the import library to the project settings. (not the *.DLL) When the O/S loads your application, the static code in the import library will load the DLL, read the EXPORT directory and fix all stubs to access the exported functions (and other symbols).
Dynamic Binding
You can omit the import library and load the DLL with your code using LoadLibrayy at the time that's appropriate. You need to define the pointers to the DLL entrypoints by yourself and must intialize theses pointers before calling GetProcAddress the actual functions.
I'm looking at incorporating Lua into a C++ project, and am a bit confused by the presence of the two binaries (lua51.dll and lua5.1.dll) in the distribution from Luabinaries.
According to the docs...
In Windows your library or application
must be linked with a stub library. A
stub library is a library with only
the function declarations that will
bind your DLL with the Lua DLL.
Why? I've never needed stub DLLs before when linking with third-party DLLs?
A stub library is a .lib file, not a DLL. It contains function declarations for all the exported functions in the DLL, which just forward the call into the DLL itself. So if you build an application that you want to link with lua51.dll, you tell the linker to link with lua51.lib, and all calls to exported functions will be forwarded to the DLL. If you didn't do this, you would get a lot of "unresolved external symbol" errors when linking.
This is only needed when statically linking with a DLL (so that it is loaded automatically when the application is run). It is not needed when loading the DLL dynamically with LoadLibrary.
Regarding why they have two different DLLs, The manual says this:
The LuaBinaries DLL packages have a dll proxy called "lua51.dll". It can be used to replace other "lua51.dll" released by other distributions. It will simply forward calls to the "lua5.1.dll". There is no compiled source code involved in the forwarding.
Basically, some existing applications link with lua5.1.dll while others link with lua51.dll and they want to support them both. In any case this is not related to the stub libraries.
I believe it's to do with __declspec(import) and __declspec(export) vs GetProcAddress. However, I don't actually know for sure.
I noticed the following about a library I use:
Library is compiled to .lib file.
My code needs to be compiled as Multi-threaded (Debug) DLL to link to this library.
I open the .sln (solution) file of the library (it is open source) and see the following in its Project properties:
Runtime Library option is set to Multi-threaded (Debug) DLL.
Configuration Type is set to Static Library (.lib)
My confusion is:
Isn't there a conflict in the library options above? (Static Library says one option, DLL says another)
What kind of an animal is a .lib that is dynamically linked? How is it different from a DLL?
Note that I am aware of the difference between static libraries and dynamic libraries in the Linux world.
The "RunTime Library" option isn't about YOUR library. It tells the compiler that you'll import your functions from MSVCRTxx.DLL at runtime.
The "configuration Type" option does refer to your library, and therefore is independent of the "RunTime Library" option.
A Windows DLL can be dynamically loaded with the LoadLibrary (or LoadLibraryEx) API, but then you have to find and bind each exported function to a function pointer using GetProcAddress or GetProcAddressEx. You'd better get the function signatures right, or Bad Things Will Happen, as usual.
A LIB file allows Windows to do all that for you when your EXE is started (including finding which DLL to use, and recursively loading dependent DLL's), linking the dynamic library statically at run time, while avoiding bloating your EXE file with the executable code, and allowing several processes to share the same DLL image in memory.
I don't know about the config mismatch, but a .LIB file when created with a .DLL library is an "export library" - it doesn't contain any code, but just the names of the callable functions and objects in the DLL. The linker uses this to satisfy references at link time which are finally resolved by dynamic loading at run-time.