maverick_pol (6th January 2008)
Let me give a more detailed explanation since you mentioned you are a newbie.
.a libraries are files which contain compiled code in an archive format. Under Linux/Unix the program ar is used to create those. Extracting a .a library gives you .o files (compiled files, object files, binary, not executable). Each .o file is the result of a single compilation (which can contain multiple source files) like "gcc -c -o myStuff.o foo.c bar.c". You would link against a .a library libfoo.a if your code shall be self sufficient in respect to code in libfoo.a which means that it should not depend on a library libfoo.so on the platform where your application runs. This can have several reasons. Eittther you are not allowed to distribute the ldynamic version of the library or your company restricts distributed binaries to be single files only. Your application would then contain all the parts (.o files) of libfoo.a which your application needs. GCC takes care of this process when your application is linked together.
.dylib on MacOS or .so files are libraries which contain essentially the same code which a static library would contain. The difference is that these libraries will be loaded by the system's dynamic library loader as soon as your application is executed. The dynamic library loader checks if your application is linked against certain libraries (at link time you specify -lfoo, really just a place holder) and looks in the dynamic library on the system for methods, functions, classes, variables, etc. which are missing in your application but in the library and makes them available to the application. The benfit is here that multiple applications can reuse the same library. This makes maintenance very easy and saves tons of space.
There are 10 people in the world. Those who understand binary and those who don't.
maverick_pol (6th January 2008)
Bookmarks