I've seen from resources that .a files are static library files for WINDOWS Systems, and that .lib files are the equivalent but for UNIX systems. I'm beginning to try to import libraries in projects and saw that for SDL2 specifically, there are .a files that I include with my linking commands with minGW is there something under the hood that is going on for these files to be read and used on a Windows machine?
I've linkedthese successfully (and not-so-successfully a few hours ago),but this bugged me so I wanted to ask you all :)
On Windows machines using MinGW, .a files (also known as static library files) are handled by the linker (ld.exe) during the linking stage of the compilation process. The linker takes the object files (.o) generated by the compiler (gcc.exe) and combines them with the code and data stored in the .a files to create a single executable file. The linker also resolves any symbol references between the object files and the library code and data.
Related
I recently made a small library in C, and I wanted to put it together with the standard libraries so I don't have to always copy the files for each new project.
Where do I have to put it so I can import it like the standard libraries?
Compiler : MinGW
OS: Windows
You need to create a library, but you don't necessarily need to put it in the same place as MinGW's standard libraries (in fact I think that's a bad idea).
It is better to put your own library/libraries in specific place and then use the -I compiler flag to tell the compiler where to find the header files (.h, .hpp, .hh) and the -L linker flag to tell the linker where to find the library archives (.a, .dll.a). If you have .dll files you should make sure they are in your PATH environment variable when you run your .exe or make sure the .dll files are copied in the same folder as your .exe.
If you use an IDE (e.g. Code::Blocks or Visual Studio Code) you can set these flags in the global IDE compiler/linker settings so you won't have to add the flags for each new project.
Then when building a project that uses your library you will need to add the -l flag with the library name to your linker flags, but without the lib prefix and without the extension (e.g. to use libmystuff.a/libmystuff.dll.a specify linker flag -lmystuff). The use of the -static flag will tell the linker to use the static library instead of the shared library if both are available.
I have created a minimal example library at https://github.com/brechtsanders/ci-test to illustrate on how to create a library that can be build both as static and shared (DLL) library on Windows, but the same code also compiles on
macOS and Linux.
If you don't use build tools like Make or CMake and want do the steps manually they would look like this for a static library:
gcc -c -o mystuff.o mystuff.c
ar cr libmystuff.a mystuff.c
To distribute the library in binary form you should distribute your header files (.h) and the library archive files (.a).
I have seen in driver libraries these three files. How are the three files related, what is the order in which the files are compiled and what is the content of each file? In addition to this I have also seen .a files are they same as .lib?
.lib and .dll files are both containers of executables of a Windows library (.o or .obj files), with the former (.lib) containing stuff (functions, definitions, etc) that you have to link statically to the executable file of your project. The latter (.dll) is either already present in your system or you put it into your system, and it is dynamically linked to the executable file of your project.
For Unix/Linux systems, the file-extensions are .a and .so respectively (that is, .a instead of .lib, and .so instead of .dll).
In all cases, when compiling your project you must #include one or more of the .h files provided to you by the library you are using (they are called header files), because that's where the stuff inside the executables of the library get defined.
EDIT
The main advantage of a statically linked library is that it is self-contained (no external dependencies) but it increases the size of your own executable file. The main disadvantage is that future versions must be re-compiled and re-distributed.
For dynamically linked libraries, we re-distribute just the updated library executables. The main disadvantage is that our program relies on the library being already installed on the customer's system.
I need to use the library libMPSSE.dll in my win32 console application project in MSVC 2010. After writing the code I just copied the dll in the folder where my .cpp file is present. I am able to compile successfully but the issue is I am having linking error:
libMPSSE.dll : fatal error LNK1107: invalid or corrupt file: cannot
read at 0x308
Is it really a problem with the dll itself or is there any problem with the dll path. How do we add dll to projects?
They have not provided any .lib file. The complete code is here
These are the usual steps to link to a DLL:
Include the DLL's header file in any of your source files that need to use functions from the DLL. You'll typically need to make sure that your build environment's include path contains the location of the header file. In the IDE you can do this using the Additional Include Directories configuration setting.
Pass the DLL's .lib file to the linker. In the IDE you do this by adding the .lib file to the Additional Dependencies setting. And you'll typically need to add the path to the .lib file to the Additional Library Directories setting.
Having done that, your program should compile and link. To make it run, you'll need to ensure that the DLL itself can be found at runtime. The simplest way to make that happen is to put it in the same directory as the executable file.
My guess, looking at your error message, is that in step 2 you passed the .dll to the linker rather than passing the .lib file.
As said here earlier you can't link to .dll files with C linker directly.
There're win32 APIs that can load the .dll file and return to you pointers to function.
Usually, .dll file is accompanied with .lib file contains code that does this burden for you and provides the API .dll file exposes. All you need is to link to this .lib file and put .dll file near the .exe file created.
Specifically regarding libMPSSE, it's said in its release notes that you can rename the provided .a file to .lib file to link to it in Visual Studio (Project properties->configuration properties->Linker->Input). I tried it and it works as supposed.
I'm currently trying to port a C application to AIX and am getting confused. What are .a and .so files and how are they used when building/running an application?
Archive libraries (.a) are statically linked i.e when you compile your program with -c option in gcc. So, if there's any change in library, you need to compile and build your code again.
The advantage of .so (shared object) over .a library is that they are linked during the runtime i.e. after creation of your .o file -o option in gcc. So, if there's any change in .so file, you don't need to recompile your main program.
But make sure that your main program is linked to the new .so file with ln command.
This will help you to build the .so files.
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
.a are static libraries. If you use code stored inside them, it's taken from them and embedded into your own binary. In Visual Studio, these would be .lib files.
.so are dynamic libraries. If you use code stored inside them, it's not taken and embedded into your own binary. Instead it's just referenced, so the binary will depend on them and the code from the so file is added/loaded at runtime. In Visual Studio/Windows these would be .dll files (with small .lib files containing linking information).
.a files are usually libraries which get statically linked (or more accurately archives), and
.so are dynamically linked libraries.
To do a port you will need the source code that was compiled to make them, or equivalent files on your AIX machine.
They are used in the linking stage. .a files are statically linked, and .so files are sort-of linked, so that the library is needed whenever you run the exe.
You can find where they are stored by looking at any of the lib directories... /usr/lib and /lib have most of them, and there is also the LIBRARY_PATH environment variable.
Wikipedia is a decent source for this info.
To learn about static library files like .a read Static libarary
To learn about shared library files like .so read Library_(computing)#Shared_libraries On this page, there is also useful info in the File naming section.
Specifications can be seen here:
http://www.winpcap.org/docs/docs_40_2/html/group__wpcapsamps.html
It's very strange,either .lib or .dll is enough IMO,why does it require both?
In general, you need the .lib for the linker, and .dll at runtime. The .lib file is called an "import library", which contains the glue that tells the linker the functions you're calling can be found in the associated .dll file.
You will probably find that only the .dll file is required at runtime.
This is a widely used layout for Win32 DLL projects and is not limited to Winpcap.
Its not only with winpcap, all external libraries are like that.
When you compiles your source codes which using particular library, you need header files *.h from that library, and you will get *.o files
When you link those *.o files to executables, you will need *.lib or *.dll.a files.
When you run those executable files, you will need *.dll files
If you are calling a Dll you will need an Lib with that. you can see the below link for more info
This is from wikipedia
Linking to dynamic libraries is usually handled by linking to an import library (your .LIB) when building or linking to create an executable file. The created executable then contains an import address table (IAT) by which all DLL function calls are referenced (each referenced DLL function contains its own entry in the IAT). At run-time, the IAT is filled with appropriate addresses that point directly to a function in the separately-loaded DLL.