views:

144

answers:

1

I've spend the morning figuring out how in a makefile to do a shared library install under Linux.

So that's fine; I now have my shared object and a pair of soft links to it, one of which was created by ldconfig and one by me.

Now, I can also build my library as a static library.

When I check /usr/lib, I see the .a files there just being...there. No symbolic links, no arrangement of version and release numbering in filenames.

Should I be arranging my static libraries with symbolic links the same way I arrange my shared objects, or is it in fact customary just to place a static library, unadorned, into /usr/local/lib?

+1  A: 

Unlike shared libraries, the static libraries placed into /lib do not participate in dynamic linking dependencies resolution. They're only used when you build your app. Therefore, there's no need to insert symbolic links and precise release numbers into their filenames.

When you link your application with a static library, the linker just embeds the code of the one it found in /lib folder. If, on the other system, the static library with same name will differ, your application even won't know about that. Because it contains the code of the static library it was compiled with and doesn't need to look up it in the system it runs on.

So, the installation of static libraries should differ from that of shared ones: no fine-grained versioning in /lib directory is actually required.

Pavel Shved
What happens if I have multiple versions of my static library, and I wish to link with different versions in different projects?
Blank Xavier
When you **build**: you prepare different instances in different directories and target your makefile towards particular one. With shared libs, it's basically the same. When you **run**: you don't need to have static libraries in your system at all, as the code in static libs is embedded into your executable.
Pavel Shved
I understand about running; you have statically linked, so by then it's all over. However, I'm noc clear about building; I have say two projects which statically link against different versions of the same third party static library. How can they differentiate between different versions of that library, when static libraries just get dumped with the same name ('library.a') into a library directory?
Blank Xavier
You can not differentiate between shared libraries either. Different versions of shared libraries exist in `/lib` not to build against them, but to **run** applications built against different versions! To build against different versions of the same library, create several **non-system** directories and set up `-L` and `-I` compiler options to point to them.
Pavel Shved
I read that the reason that 'library.so' is a soft link is so you can build against library versions other than the latest version, e.g. you point the linkname the linker will find to the version you want to build against, while the other linknames point to the latest release of their version of the library (so you can run against them).
Blank Xavier
That is right, but you seem to misunderstand what it means. You indeed can build against non-latest versions, but *this building happens not on the machine in subject, but rather, on the other machine*! You also seem to mingle "linker" (`ld` program) and "dynamic linker" (program that finds proper `so` files at startup). Try to consider another point: header files in `/usr/include` are not soft links, and they all correspond to latest version installed. Anyway, please, try to read more info about shared libraries; try here: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Pavel Shved