I don't know C, but need to interact with some C files in a project. I'm noticing that some files have .lib extension, while others (which are also supposed to be libraries) have .c and .h files only in a big folder.
What's the difference between these libraries.
Are the .c and .h folders also libraries.
Is the .lib format the official format for libraries and these guys who did .c and .h just lazy or not using best practice?
.c and .h files are source code, i.e., text files. In order to "use" them (i.e., execute the code on a computer) you need to compile them into...
a .lib file is the end result, i.e., a binary file. It can be statically lined into another executable and the code run on a computer. This saves you the time of compiling the source if you don't need to.
.lib is just one common extension, but it doesn't really matter what the extension is as long as the file is valid. Point your compiler/linker to the .whatever library file and let 'er rip, it will all work out in the end.
C static libraries are usually compiled in .lib on Windows and .a or .so on Linux/Unix. But extension is just a matter of convenience: "do you have that lib in a repo!?"
as to .h and .c they are as valid, but just not compiled.
You can use both approaches without fear, even if the extension is .darthvader
Compiler does not care about the extension as long as the file is specified. I name my libraries .a. Commonly, source files are named as .c, and header files as .h. But this just for mere convenience, a compiler will work on any valid source file, no matter the name.
The standard file extension for programs written in C is .c, header files that come with a project carry the extension .h.
.lib is just some programmers choice to name their library file. It usually stands for a compiled binary which can be statically linked into another executable file. Other common file extension are .a and .so (especially on *NIX machines).
Related
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.
I downloaded the libftp source from here, and compiled it using make. Now I just have a binary called "ftp" in the same directory. Do I need to move it to one of the root directories, like /usr/bin? Do I still need the source files so that I can #include the library?
To use a library in your own code, first you need that library - generally named lib{name}.a or lib{name}.so. The library will be required during linking. So when you make, make sure it creates the library and not just the ftp binary.
Secondly, at compile time you will need the header files so that the #include's don't throw errors. So as far as source goes, you will at least need the header files.
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'm working on a project from school, and we were given a .o and a corresponding .h file.
We need to use several functions from the .o file in our .c program.
Just placing it in the same directory doesn't work.
I tried to look for something like this in the project properties, but no good.
I keep getting ../code_files/Search.c:116: undefined reference to 'reportError'
I'm using Eclipse (Juno) CDT, gcc MinGW under Windows 7
I know it's possible to include .a files, but I couldn't find any indication on how to include a .o file
#include "ErrorHandle.h" is included in the main c file.
Anyone knows how to include a .o file to a project?
Thanks!
I found this answer:
I tried doing something similar, only I didn't think of the miscellaneous thing
You can trivially turn the .o into a .a with ar cvs library.a object.o, and then add the .a to your project.
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.