Getconf returns compiler flags that the compiler warns about

Question

I have Workshop 12u1 installed on my Solaris 10u8 machine (x86_64). I'm up to date with patches as of a couple weeks ago.
I'm well aware that the Workshop suite has deprecated flags like -xarch=generic64, -xarch=amd64a, etc.
However, when I run "getconf" on my Solaris 10 system, some of the conf settings still return those older flags that the compiler now warns about. That causes a lot of warning chatter when building certain applications (e.g. perl 5.10.1) that are smart enough to use "getconf" to try determine what flags to use in certain situations. Using getconf to find the right flags is even mentioned in the standards(5) page, but following its advice results in deprecation warnings from the compiler. Not good.
If you run the following code you'll see what I mean:
for f in `man getconf | egrep 'XBS'`; do echo "Checking $f"; getconf "$f"; doneIs this something that I (as a sysadmin for the system) should be able to configure, or is it something that would need to be patched to fix? The man pages for getconf, sysconf, and confstr aren't clear where the values are actually coming from.
So, how should this be fixed?
Thanks,
Tim

Answer 1

Enchanter wrote:
Since I'm running regular old Solaris 10, rather than OpenSolaris, I'm skeptical how much help the OpenSolaris developers are truly going to be. I can certainly give it a go, but even if they fix it in OpenSolaris, it might be a very long time before that fix filters into Solaris.Actually, it goes the other way. New features and modification go into the internal Solaris development workspace before they migrate to Open Solaris. The Solaris Express and final releases and Open Solaris releases come from the same source base. Whether a feature or update goes into a Solaris 10 patch depends partly on demand, especially demand from customers with service contracts.
I'm also a little puzzled about the "backwards compatibility" thinking of the compiler developers. In some areas (e.g. C++ and the standard library), what's shipped with the compiler is years and years behind what's current, apparently in the name of "backward compatibility". Yet where compiler flags are concerned, the developers seem to be much more cavalier about deprecating things and making changes that break backward compatibility.We try very hard not to break code or makefiles. Sun (and now Oracle) makes its money from enterprise users. Their code bases last for a long time, and changes are expensive. Changing a line in a makefile or source code file can mean having to re-certify the application.
The change from -xarch to -m specifying the memory model was more abrupt than we would have liked, and in hindsight, was probably not handled very well. We were running into combinatorial explosion of -xarch sub-options due to the increasing number of architectures that the compiler supports. Some option combinations quietly resulted in behavior that you didn't expect. (For example, the combination "*-fast -xarch=v9*"did not give the same result as "*-xarch=v9 -fast*".) Separating memory model from the other considerations made the options easier and more reliable to use.
Don't get me wrong -- I'm all for forward progress with the tool-chain -- I think that the C++ standard library and the defaults should all be brought up to what's current in the industry. Sun Studio 12 update 1 has direct support for Apache stdcxx (if installed in a standard location) in addition to libCstd and STLport. The Apache library will be in the next Open Solaris. When it will be available in a Solaris 10 update has not yet been decided.
I also think adding support for -m32/-m64 was a good move. It just seems to me that if the developers are going to deprecate a large number of flags that the compiler accepts, they should also make certain that the rest of the operating system can handle that change. To me, that means that they need to work with the developers of getconf/confstr() to make certain it knows how to check the compiler version before it emits a particular flag.Only a few options have been deprecated. It's just that they are probably the ones you used most. :-(
More than one compiler version can be installed on a system, and compilers can be installed anywhere. Programmers in medium to large shops typically run compilers installed on a remote server, although they might have other compilers installed locally. If getconf had to guess what compiler you were using, it would often guess wrong. If you have suggestions on how to match up getconf behavior with the compiler you want to use, please post them in an Open Solaris forum.