Pages

Wednesday, June 7, 2017

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
The first option ("") also serves to definitely show that there's absolutely nothing wrong with my system setup and that there's something bad elsewhere. If I do not use -std=c++11 or -std=c+14 then I get the correct behavior but then I loose C++11 or C++14, which is unacceptable. I don't have an Oracle support plan but even so I don't believe they have a fix for that as it seems they are stuck with older GCC versions anyway.

Hence, the only possibility left to check was to attempt myself a challenging build of the latest and greatest GCC on Solaris 11.3 x86_64 platform! As I need C++11 badly as well as Solaris 11 I had no other choice. So I set out to a manual installation of the latest version of GCC (at the time of this writing, 7.1!).

As to plataform specific notes it seems that there's no real issue, but on the contrary there's a surprisingly and welcome note explaining how to configure the build in order to have GCC generating 64-bit code by default, instead of being locked to the annoying task of setting up the -m64 flag to every new project! To "quote" what that part of the document amounts to:
 
To configure and build this way,
provide all support libraries (like libgmp) as 64-bit code, and configure with --target=x86_64-pc-solaris2.1x and ‘CC=gcc -m64’.

Of course, there's a lot of additional preparations, reasonably organized as a lengthy series of prerequisites, but as I shall demonstrate in a subsequent post, they can all be satisfied by a Solaris 11.3 GA release, with the sole exception for automake, which the highest version provided in Solaris 11.3 (GA / Release) is 1.11.2 and the required one is 1.11.6. To address this single exception it'll be necessary to perform a manual build of automake-1.11.6, which fortunately is not that difficult at all as I shall show later too. Nevertheless, I must point out that a build verification of automake-1.11.6 under Solaris 11.3 x86_64 reports the following results (I reported these 2 failures and 172 skips and they told me that version 1.11.6 is rather old in face of version 1.15 which I should try instead):

=====================================
2 of 779 tests failed
(172 tests were not run)
...
=====================================

You may find interesting that according to the build status of GCC 6 series, you'll find many Solaris versions, 10, 11 and 12(!!!) for i386 and sparc, though none of them are 64-bit, yet... So I would still hope in being successful with GCC 7.1. We'll see... :-)

The conclusion is that it may really makes sense manually building the latest version of GCC as a non-commercial solution for having up-to-date C++ in a Solaris 11.3 platform, even if the generated code isn't the most optimized one. The optimization argument here is far less important than the amount of coding enhancements brought by C++11 and C++14, needless to say that as times passes things always evolve and native compilers shall catch up sooner or later, but the code needs to born today with no further delays!

NOTE
Since Solaris 11.4 Beta the GCC version has bumped to 5.5.0 theoretically supporting the full standards of C11 and C++11. In addition the whole userland seems finally migrating to 64-bits as revelead by the taget-triplet x86_64-pc-solaris2.11 from GCC. Nevertheless, the locales issue remains. The good news are that most tools have newer versions as well which should help getting success from a manual build that fully works as expected!
NOTE
I have found that this issue has no easy solution.