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