From my knowledge, *.pc files store metadata about shared libraries. Does the linker automatically use these files when linking against a shared library? If so, where does it search for these files?
No, the linker does not utilize .pc files. Those files are for pkg-config, which can in turn be used to generate commands to link.
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'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.
I downloaded this: https://github.com/mongodb/mongo-c-driver
And now I'm trying to use it inside my C program, but I don't know what to do with the generated .a files. What are they? I couldn't find any information, not even in the GCC manual.
And I built it like so:
scons --c99
Also, can I use C99 libraries with my C89 program?
.a files are static libraries typically generated by the archive tool. You usually include the header files associated with that static library and then link to the library when you are compiling.
.a files are created with the ar utility, and they are libraries. To use it with gcc, collect all .a files in a lib/ folder and then link with -L lib/ and -l<name of specific library>.
Collection of all .a files into lib/ is optional. Doing so makes for better looking directories with nice separation of code and libraries, IMHO.
Are library files .o or .exe files in C?
Neither; generally .o files are object files and .exe files are fully-linked binaries (on Windows).
Static libraries in Linux are .a
Dynamic libraries in Linux are .so
Static libraries in Windows are .lib
Dynamic libraries in Windows are .dll
It's more operating system dependent than language dependent.
In Windows, they are likely to be .dll files.
In Linux, they are likely to be .a or .so files.
In OS X, they are likely to be .a, .so or .dylib files.
Neither. It also depends on the platform. Also, the file extension is only convention and libraries can have any other or no extension at all.
The answer is libraries are neither *.o or *.exe. Also the naming convention depends on the Platform you are compiling.
A *.so file is a shared lib. *.a is a static library on the Linux platform.
You can specify options at compile time to build the libraries.
Here you can check more about shared libraries and compilation and build options for the same.
In linux, library files are an archive of one or more .o files. Linux uses the 'ar' program ( think 'tar' without the tape ), to create the archive. After bundling them together, you then use the ranlib program to add some indexing.
ar rc mylib.a source1.o source2.o source3.o
ranlib mylib.a
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.