Shared Libraries - Solaris 11.3

Although I've already posted about shared library naming and versioning conventions and have already given a first example I consider interesting, there's, of course, much more about this subject.

It seems that fortunately Solaris 11.3 Information Library on its section on Developing Applications For Use With Solaris 11 at the chapter on Solaris 11.3 Linkers and Libraries Guide provides a lot of knowledgeable information on the topics. From what I've seen, a must read for expanding the vision on yet more powerful options that may lead someone to the next level towards the elite.

Shared Libraries - Example #1

Let's try a first example of a fictitious dynamic application (one that links to dynamic objects ‒ a shared library in this case). The key aspects I wish to address on this post are how to build these artifacts under Solaris 11.3 using GCC 4.8.2 and properly adhering to the versioning naming convention. I would like to emphasize that in the name of straightforward software engineering there will be no excessively elaborated interfaces strategies, for instance by using crazy things such as GUIDs (or so) or any other related / similar interface infrastructure (if you like GUIDs you may perhaps have some fun playing with a GUID generator). My strategy is pure C++ resulting in a much more powerful, efficient and higher-quality artifact than some sort of software crazy and buggy Frankenstein monster such as COM and related. I'll be using C++ namespaces and a main C++ class on each library module.

The software engineering implementation/deployment depicted on this example consists (for the sake of simplicity) on a single (do-nothing) shared library and a (stub) dynamic application linking to it just for testing and demonstration. I'll build 2 major versions of the library (libgreeting.so.1 and libgreeting.so.2) the first of them with some different minor versions and releases (for demonstration purposes). For each major version of the library I'll show a backward compatibility tehcnique for avoiding or minimizing the rebuild of the application (myapp-1). Accompanying each new major version of the library there will be (for the sake of simplicity) a new / updated header-file which as I said will provide for backward compatibility with previous major version(s). The header-files shouldn't be modified within minor versions and releases as this would be a clear deviation of whole strategy. For demonstration purposes, the implementation of each interface will consist on multiple source-code files. Besides the interface mechanism the library will be able to "report" its hard-coded versioning information (as a kind of reflection) which will always correspond to the name of the shared library version final binary object, although (again for the sake of simplicity) there will be no provisions to enforce this correspondence.

I can only hope that the software engineering aspects I'll be exploring side-by-side do not hinder the main goals of this post about building and dealing with shared libraries!