C++ Locales under GCC

The C++ locales is a cool feature for software internationalization and everybody certainly knows about or have heard of it. But when trying to use it on anything but a Windows or Linux system one may find out a crippled implementation. This is the case when GCC is ported to a different platform such as Solaris.

At first I thought it could be a simple matter of getting a more updated version of GCC. Then I've tried to document the potential solution on a previous post. But while digging into the matter I've sadly realized it's a more complicated issue.

As a matter of fact the issue lies in GNU libstdc++ which unfortunately does not provide a complete implementation of Locales. Its implementation is target just for systems already possessing a working implementation of the GNU C Library (glibc) which offers a key function usually found at newlocale.c source module that exposes the "special property" of being thread safe" at the C++ level". Solaris, as a standard UNIX system, uses libc which is thread safe just at the C level. Hence, GNU works around the issue by providing what is called a "general stub" only supporting "C"  (= "POSIX") locale and otherwise throwing an exception. This has been made clear as per the following archived message: generic locale.

It seems that the main issue is an underlying libc limitation of not providing necessary API points for building up a multithreaded implementation of libstdc++ on top of it. As a consequence one entirely lacks a key C++ feature because of an unresolved multithreading issue. At this point it turns out easier to understand why there's a GNU C Library on the first place and why GNU libstdc++ relies on it instead of a particular system's libc.

But wondering about this multithreading issue between the C and C++ libraries when dealing with other locale dependent calls, one could realized that in most cases all that's necessary is to simply set the locale once on start-up code or while entering the main thread. From that point on, as long as a program remains pure C++ at the locale-dependent high-level I/O calls all should work pretty well.
 
I mean that in general a program isn't expected to be switching locales anymore after having properly intialized itself. I know I could be missing many reasons why the contrary should hold, but it seems they all would narrow down to some processing that should be carried out multiple times (in parallel) for different locales, such as processing some sort of localized I/O to several branch offices under a single process.

Therefore due to strictness, an all or nothing situation, one ends up with virtually nothing at all under Solaris and other less popular platforms for which nobody else carried about on providing a slightly more decent implementation of the C++ standard :-(
 

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!

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