Technically they are replaceable (our initial -compat=g implementation was able to use whatever GCC installed on a platform).
However each new GCC version introduces a new code in the headers and sometimes this code is rather non-standard (say, it uses C++14 in C++11 headers, or C++11 in C++03 headers).
Each time switching to the newer headers/runtime we discover a couple of these issues and apply workarounds for them.
So you cant replace the headers/runtime arbitrarily and expect them to work right away.
Besides, as we cant possibly test all the different GCC versions, we cant provide good support for the versions that we did not test against.
PS. Oh, and all that was about -std=c++11
> the -std=c++11 and -std=c11
-std=c11 is implemented in a C frontend and it does not use gcc headers/runtime *at all*.
First, about replacing headers and libraries, the short version of Fedor's comments is this:
We do not support replacing headers or runitme libraries in any of the modes that use the gcc library:
-compat=g, -std=c++03, -std=c++11
Regarding interactions of the -std=c++11 options with other options: The documentation lists all known issues. In the C++ Users Guide, see the Appendix that discusses compiler options. Look up options you want to use and see where there are any limitations. The examples you list do not have restrictions, but I can't comment on "etc". :-)
Regarding compatibility: We do not promise compatibility for Beta releases. Beta releases often contain bugs or incomplete features that affect compatibility. When switching to an updated Beta or to the final release, you should recompile all your code. Note: When you download the Beta, you first have to agree to the license terms, which in particular say that you cannot use the Beta for production code, nor can you distribute code that you create with the Beta version.
Regarding the final release of Studio 12.4: The modes that use the gcc headers and library are not compatible with code produced by earlier compilers. We cannot say anything now about compatibility with future releases. But we are using gcc libraries, and gcc says that future releases will not be compatible with the release that we are using. The reason is that the 4.8.x libraries (which will be in the next Beta) are a work in progress.
Currently, do you further envisage updating of CC-gcc libraries and bundled STLport in a final release of 12.4 and possibly after the final release? Assuming that the updates are done after the 12.4 final release, will it be made free (similar to Sun Studio 12 Update 1) or does it require an active Oracle Support Contract? Kindly advise.
Ah. Questions I can answer. :-)
The final release of Studio 12.4 will use the same C++ library versions (Sun and gcc) that are in the July Beta update.
Apart from bug fixes, we have not updated STLport for many years. There are more recent versions of STLport, but they are neither source nor binary compatible with the release we provide. That's the reason we have not adopted a more recent version. The major feature missing in STLport is support for locales. The more recent versions still have no support for locales, another reason for not updating. There is no community effort to update STLport to C++11 or beyond.
The Apache stdcxx library that ships with Solaris 10u10 and Solaris 11 is a full-featured, standard-conforming C++03 library. If you have the option of using it, it is probably the best solution to a having a stable library available for clients of your application. You don't have to ship a library with your app (as you would with STLport), and you don't need a special library runpath to access the library, since it is in /usr/lib. As with STLport, there is no community effort to update it to C++11 or beyond.
Studio releases are free for all uses. I don't know of any plans to charge fees for future Studio releases. Studio historically has not had updates in the way that Solaris does, just releases and patches. I don't know of any plans to provide Studio updates in the Solaris style. Well, there are updates of a sort. Studio 12.3 had an updated release to provide direct support for new processor versions. Studio 12.4 probably will, based on projected release dates of Studio and new hardware. These are called Processor-Specific Enhancement (PSE) releases, and apart from possible high-severity bug fixes, contain only enhancements for new processors.
Patches for Studio require an Oracle Studio service contract.
I have 3 questions:
- For patches downloaded from My Oracle Support (MOS), are there any license restrictions in terms for redistribution and usage? [I am thinking of getting the Oracle Studio service contract.]
- Are there plans to apply some patches from previous Studio versions to the 12.4 final release, under a scenario where some bugs might have been fixed in previous versions but not yet present in 12.4?
- For Processor-Specific Enhancement (PSE) releases, I presume that they will be following the 12.3 style, in which an Oracle Studio service contract will be required, though I am unsure whether it will be the same as 12.4 release.
1. I don't actually understand what you have in mind. Maybe your friend has Solaris Studio but not a service contract, so you want to give him a copy of the patches you downloaded? You can't do that. See the license agreement for more details.
Some binaries that are part of Solaris Studio are allowed to be redistributed. They are listed in the Distribution Readme on the online documentation page for the release. For example, here is the Studio 12.3 version: Oracle Solaris Studio 12.3 Distribution Readme
2. We try very hard to ensure that all bugs fixed in a previous release are also fixed in the current release. Generally, we fix a bug first in the release under development if it is present there, then in earlier releases, working backwards. So it should not be the case that a bug that was fixed in an earlier release is present in a later release having current patches.
3. A PSE "release" is really just a set of patches, so I would expect that a service contract would be required to get it.
I lot of factors went into selecting the runtime library. At the time we selected the runtime library, Clang's was not of production quality. In addition, we wanted to provide gcc binary compatibility, which requires using the gcc library.
The gcc library does not use the GPL, or we would not have chosen it. The library uses the LGPL, which is far more liberal, and seldom creates problems for application developers. For details, consult the license.
That's about all I can say on this topic. And to forestall the obvious next question, I can't speculate on what we might do in a future release.
> At the time we selected the runtime library, Clang's was not of production quality
Besides, even x86-Solaris is not listed as a supported platform for libc++.
It might accidentally compile but thats not a level of support we need.
And I wouldnt dare to try it on Sparc-Solaris...
Say, this is a typical situation with clang on Sparc:
I did not try it but I bet libc++ is not any better.