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!

Shared Libraries - naming & versioning

The convention of UNIX shared libraries names may be somewhat puzzling because it appears different systems may not strictly adhere to the convention. What makes most sense appears to be the convention followed on Linux and (apparently) not quite strictly followed on Solaris. On this post I'll try to make a better sense of this in order to discover the right (or at least best) way of doing things in Solaris.

GCC under Solaris 11.4 Beta (refresh)

About 2 months ago I've posted about the availability of GCC 5.5.0 under Solaris 11.4 Beta. Today I've just got to know through my Linked-in connections that everything has been refreshed and that now GCC 7.3 is available. I'm still not believing but at some point I'm going to check it out!

The RLE configuration

It's been a while since I last dropped a line into this blog. That's not because I've neglected it but because there's been so much to learn in C++ and a wealth of other technologies and metodologies that it gets hard to find time to write all of my findings. But anyway here I am and let's go again.

GCC under Solaris 11.4 Beta

It's been quite a while since the last publicly available version of GCC under Solaris.
Particularly under Solaris 11.3 I've described how to install it long ago.
With the release of Solaris 11.4 Beta I decided to quickly review it.

# pkg info -r gcc
          Name: developer/gcc
       Summary: GCC
      Category: Dev.../C (org.opensolaris.category.2008) Dev.../C++
                (org.opensolaris.category.2008) Dev.../Fortran
                (org.opensolaris.category.2008) De.../GNU
                (org.opensolaris.category.2008) Dev.../Objective C
                (org.opensolaris.category.2008)
         State: Not installed
     Publisher: solaris
       Version: 5.5.0
        Branch: 11.4.0.0.0.12.0
Packaging Date: Wed Jan 03 02:32:06 2018
          Size: 2.52 kB
          FMRI: pkg://.../developer/gcc@5.5.0-11.4.0.0.0.12.0:...
   Project URL: http://gcc.gnu.org/
    Source URL: http://ftp.gnu.org/.../gcc-5.5.0.tar.gz

GNU - Build preparation

OUT OF DATE

It's no doubt very convenient and trustworthy to install new software through IPS or even the legacy SVr4 packages. But when those options are not available fortunately there's still a chance for the GNU build automation, which although not as convenient can also perform a good job.

The well-known essentials of GNU build automation end-user operation work-flow was the subject of another post, in which I hopefully confirmed to work reasonably with a few adjustments under Solaris 11.3 and in which I successfully integrated some well-known ZFS essential advantages, such as source-tree snapshots.

In this post I hope to somewhat complement what's been discussed by presenting a suggestion of Shell script to hopefully simplify and avoid some common mistakes in the preparation of the GNU build automation work-flow environment.

For instance, assume that an application source code (tarball app-1.0.0.tar.gz) is to be built for both 32-bit and 64-bit targets using GNU tools and that the build operation is to take place at a local staff /software/build with the results installed locally under /software/prototype.

NOTE

I assume that the source code tarball is usually named under the following convention: name-version.tar.compression.

But there are cases this convention varies, for instance. node.js prepends a v before version, which slight variation, in this particular case, is a minor annoyance and fortunately won't break the following script. After the script is run, if desired, one can rename the datasets accordingly in order to normalize things, by removing the v before version number.

But there are other cases such as maven (apache-maven-3.5.3-src.tar.gz) where the tarball name would break the script. I could attempt fixing it, but as there are so many unpredictable possibilities this would certainly become a unmanageable.
 
The general solution is to conform the tarballs' names to my original assumption, usually with a simple manual procedure (as root) of extracting the archive and then storing everything back under a conformant archive name. For instance:
 
# cd /tmp
# gtar xf .../maven/3.5.3/apache-maven-3.5.3-src.tar.gz
# gtar czf maven-3.5.3.tar.gz maven-3.5.3
# cp maven-3.5.3.tar.gz .../maven/3.5.3/
 
As an alternative while recreating the tarball, one can attempt higher compression rates with j (for a .bz2) or J (for a .xz) instead of just z (for a more common .gz compressed file). On this particular example the sizes become: 2.6M (.gz), 2.2M (.bz2) and 1.8M (.xz).

GNU - Build Automation

Solaris 11.3 includes many modern packages, among them some essential GNU build automation ones. The problem is that the pace of update of these third-party packages is much faster than what get updated through support repository, needless to say the public release repository. In order to better keep up with this third-party pace, there's no other better alternative than to get the sources and build ourselves what's needed, in the hope (and unfortunately sometimes it's no more than just a hope) that the sources and the build tools are compatible and available to Solaris.

Source-tree snapshots

While setting to build projects which source-codes are distributed as a source-code tarball it's convenient to prepare some grounds before simply extracting the tarball to a plain directory on a "general" file-system. That's because while fine-tuning or experimenting on building the project it's often necessary to keep track or manage the state of the source-code tree in order to not mess things up.

In Solaris, part of this ground preparation is particularly powerful and elegant by virtue of the ZFS, specially due to the possibility of easy snapshot, clone, hold / release, send / receive and rollback operations. To take advantage of all this power it's necessary to set up some delegated ZFS permissions to the base dataset where the source-code tree will reside. This dataset could be remote, shared via NFS or SMB, but more typically it is local to an individual developer system and usually located as a descendant to its home directory.

GCC - library search dirs

Again, among a lot of detail to pay attention when compiling and linking a program is where the default libraries are being looked for. The general answer found everywhere is: "In the default system locations". But that may be vague, so here's my refinement to that general anwser, for instance, for GCC:

GCC - why build

I was studying C++11 when I faced an awful bug regarding locales in the Solaris 11.3 x86_64 platform either on plain GCC 4.8.2 or Developer Studio 12.5 which for C++11 relies on a GCC library by means of the -std=c++11 compiler flag. Simply put the feature doesn't work at all, except for C or POSIX locales, which are essentially the one and the same as the traditional USA localization since the legacy C era. It doesn't matter if I attempt any of the following forms:

...
std::locale user_native( "" )
...

 or

...
std::locale en_US( "en_US.UTF-8" )
...

Both forms fail badly with the following ugly message:

terminate ... throwing ... 'std::runtime_error'
... locale::facet::_S_create_c_locale ... not valid
Abort