Reputation: 11045
Let's describe the following scenario:
I intend to create an application for the Linux platform
The application will contain a core shared/dynamic library and the executable. The library will act like an engine, providing common and essential classes and functions.
Now, I know that both the library and executable may change over time and I want to make sure that each executable knows what library is for it and in case the library version is different it will show a message about the library being two old (this could be a constant, abiding by the ABI rules, that will always contain the version and will be checked against the executable's version at the beginning of the entry point).
I have read the ABI specifications and rules and I don't like them (too strict). I don't want to have a single library on the user's system, which I update and try to keep compatible with older executables. I prefer, because I don't know how the interface will change and I want to reserve myself the freedom of doing any change later, to have each executable with its own library version on the user's machine. For example:
In Linux, we have the version numbers at the end of the .so libraries. Does this give us the possibility to have multiple versions of the same library and each executable linked to its own library version?
Upvotes: 2
Views: 774
Reputation: 2320
This should be a entry point:
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Upvotes: 3
Reputation: 1
Read Drepper's paper: How To Write Shared Libraries
The version 1.0 of your library should generally change only for incompatible API changes.
Upvotes: 1