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 :-(
 

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

GCC under DOS

It's almost incredible but GCC 5.2.0 runs under DOS on Intel 386!
Of course, there's a 32-bits DOS Extender under the hood, but anyways!
That were made possible thanks to the heroic Deloire DJGPP project.
That's an incredible achievement constrained by DOS limitations.
Naturally there are not threads under DOS, please!
But it allows you to have a great start in C++11.

Nowadays, having a virtualized DOS is easy. You can use VirtualBox, VirtualPC, and so on... The list is quite extensive. And in face of actual powerful machines and sophisticated Operating Systems the requirements to a virtual DOS are trivially fulfilled! Booting a virtual DOS is ridiculously fast. Aside from obvious restrictions from DOS (as for lack of threads), the only slightly strange is that the generated executables are excessive large (as if many libraries were statically linked in), over 1Mb, even for the insidious "Hello, world!" minimal program. But never mind, if you follow the proper steps you can live with it and compilation times aren't that bad (for a DOS).

In order to get DJGPP, the recommended approach is to visit:
http://www.delorie.com/djgpp/zip-picker.html

I think it's best not to download too much stuff, so I stuck to the minimals as seen on the above image. Once the choices are made, just click the "Tell me which files I need" and follow the instructions. By the way, there's nothing hard about the instructions. Just note that you should use the default directory C:\DJGPP, the provided unzip32 and do a couple of very simple environment variable settings (one for DJGPP and other to your PATH).

By the way, note that differently from when under a Linux or UNIX platform, the C++ compiler executable is called gpp and not usual g++ as this last one amounts to an invalid file name under wonderful DOS world.

NOTE

In addition to DOS, as long as you stick to a 32-bits world, even those provided by Windows XP and Windows 7 (32-bits), you can still you the same approach depicted above, though you should select a closer match on the drop-down list-box which operating system you'll be using. You should select Windows 2000/XP. You should get a slightly different set of files, but not that much. I know that by doing this you'll even get GCC 5.3.0 (by the time of this writing).

   

GCC under Solaris

Solaris has been evolving and being modernized a lot.
That's very welcome since it's been always a great OS!
Thus it's now much easier to get GCC working under Solaris!
The Solaris 11.3 generally available release offers GCC 4.8.2.
That's more than enough to get our fit wet with C++11.
Once a local package repository is available you just have to do:

# pkg install gcc
...

# pkg install gdb
...

NOTE

Instead of the two commands above it may be sliglhtly better to adopt the following alternative:

# pkg install --be-name developer-gnu developer-gnu

And if you want to be a little bit more cautious just add the --be-name switch in order to designate a new boot environment (BE) under which the gcc and gdb packages are to be installed. In case you take this path after a successful completion of the commands you'll have to reboot the system into the newly created BE.

In the end you can confirm what's at your disposal as follows:

# pkg info -r gcc
          Name: developer/gcc
       Summary: GCC
      Category: Development/C (...)
                Development/C++ (...)
                Development/Fortran (...)
                Development/GNU (...)
                Development/Objective C (...)
         State: Installed
     Publisher: solaris
       Version: 4.8.2
 Build Release: 5.11
        Branch: 0.175.3.0.0.30.0
Packaging Date: August 21, 2015 04:45:27 PM
          Size: 5.46 kB
          FMRI: pkg://.../gcc@4.8.2,5.11-0.175.3.0.0.30...

# pkg info -r gdb
          Name: developer/debug/gdb
       Summary: GDB 7.6
   Description: GDB, the GNU Debugger, is a ...
      Category: Development/System
         State: Installed
     Publisher: solaris
       Version: 7.6
 Build Release: 5.11
        Branch: 0.175.3.0.0.30.0
Packaging Date: August 21, 2015 04:35:57 PM
          Size: 8.93 MB
          FMRI: pkg://.../gdb@7.6,5.11-0.175.3.0.0.30...

Pretty fast, simple and cool, isn't it?
By the way, the IPS takes care of everything!
You don't have to manually tweak absolutely nothing!

NOTE

Yes, it's true that GCC is not a native compiler to Solaris and as such it will never be able to generate the most streamlined and efficient code to the platform. But as a learn and a project started tool is a quite good solution. Later on, if your project become successful you can consider the platform's native compiler and tools Oracle Solaris Studio.