Sun Studio 12 CC compiler and gcc libraries

Hi
We are working on a porting project, Linux to Solaris. The software uses lots ot third party libraries. These libraries are compiled on Linux using gcc. They do not endorse Sun's CC compiler.
Our project plans to use CC instead. Is it okay to build our software with CC (and fix all the portability issues we may have) and finally link it with all the third party libs created with gcc ? Is such kind of arrangement workable?
Any advice would be really helpful.
Thank you,
Manish.

Thank you for reporting the problem! I've submitted CR 6642662. It should be visible on web in a day or so.
Boris

Similar Messages

New Language Extensions in Sun Studio 12 C Compiler

Sun Studio software engineer Dmitry Mikhailichenko gives an overview of some of the C-language extensions introduced in Sun Studio 12. Although some of these extensions are not part of the latest C99 standard, they are supported by the gcc compiler.
The article also demonstrates how to use the new C features for creating generic macros with an example of linked-list manipulation-routines. Such macros semantically mimic C++ Standard Template Library, support arbitrary data types and provide strict compile-time type-checking.
Read the entire article at http://developers.sun.com/solaris/articles/c_type.html and leave your comments in this forum entry. We'd like to know what you think about these extensions and if you have additional suggestions for the Sun Studio compiler team.

Thank you for reporting the problem! I've submitted CR 6642662. It should be visible on web in a day or so.
Boris

Sun Studio code hangs at fork, GCC code runs fine

I am encountering a strange problem where code complied with GCC runs fine, but the same code compiled with Sun Studio 12 compiler hangs at a fork call after an initial set of fork calls.
I'd appreciate your help in solving this.
The code was originally written for GCC, I started using the Sun Studio with a view to using Sun's thread analyzer. I made a couple of changes which I think are inoccuous:
(a) added #ifdef __SUNPRO_CC char * __FUNCTION__ = "name"; #endif
(b) one more #ifdef around one call to ctime_r because the g++ include expects 2 parameters while Sun Studio 12 expects 3 parameters.
The g++ is compiled on a Solaris 9 (1 x sparcv9) using GCC 3.3.3
while the Sun Studio 12 is on a Solaris 10 ( 4 x sparcv9).
Both runs were on the same Solaris 10 machine which has the compiler.
The program is a multi instance socket listener, the main program binds to a socket, then forks off a set of processes which accept connections, those children later fork off other client applications based on the connection data; after those clients exit, the children continue accepting etc. The main program only monitors the child processes, records their status and starts if any of those die.
This is working as expected when compiled with g++.
The exact same code (note the two sets of #ifdefs above) when compiled with Sun PRO CC alway hangs at the second set of fork. That is, it goes through the first set of forks fine, then when a connection is established, it reads the data but hangs right at the fork call.
The application code at this point is:
char * p = pathfind( getenv("PATH"), progname );
if ( !p ) { printError(); return false; }
pid = fork();
The truss for the Sun Studio code shows
23914: access("/usr/bin/progname", X_OK) = Err#2 ENOENT
23914: access("/usr/you/bin/progname", X_OK) = 0
23914: lwp_park(0x0000000, 0) (sleeping)
while the truss for the g++ code shows
23986: access("/usr/bin/progname", X_OK) = Err#2 ENOENT
23986: access("/usr/you/bin/progname", X_OK) = 0
23996: fork1() = 24005
What am I doing wrong?
Thanks and best regards

If I understand correctly, you are compiling with gcc on Solaris 9, and with Sun Studio on Solaris 10. Since the OS is different, you might be running into OS issues and not compiler issues. What happens if you build with the same gcc version on the Solaris 10 system where you see the problem?
By "OS issues", I mean
1. The program uses unstable or undocumented OS interfaces, or
2. A bug that is new in Solaris 10.
A bug was identified in Solaris 10 that could cause forks to hang. It showed up in the libpkcs11 library as used by the JVM. I don't know whether it showed up elsewhere.
This bug was fixed in Solaris 10u2. If you are using an earlier version of Solaris 10, you could try upgrading.

Sun Studio 11- Now Available (and FREE)

Howdy,
Today, Sun announced the availability of Sun Studio 11, the latest release of our venerable set of optimizing compilers and tools. We are very excited about this release for many reasons, including:
* Record-setting optimizing C,C++,Fortran compilers
App performance =� Platform + OS + Compilers/Tools
Using the latest SPARC/x64/x86-systems and Solaris/OpenSolaris versions is great. But to get maximum performance for your app, you need to upgrade to Sun Studio 11.
http://www.sun.com/software/products/studio/benchmarks.xml
* Exploits multicore (CMT) systems for maximum throughput performance
- Multicore optimizations (UltraSPARC, x64)
- OpenMP 2.5 support with autoscoping across all compilers
- Support for OpenMP/Solaris/Posix threads in debugger & performance analyzer
- Dataspace profiling provides hardware and program views into the performance costs associated with application memory references
* Providing Platform Choice: Solaris 8,9,10 (SPARC, x64, x86) and RHEL 4/SLES 9
- Optimizing compilers with Solaris versions only
- Linux version has debugger, performance analyzer, IDE, etc.
- Technology preview of Linux compilers:
http://developer.sun.com/sunstudio/linux
* FREE, unrestricted license (no gotchas)
Sun Studio has been a good and growing business for Sun, but our intent is very transparent with this pricing model change- we want to accelerate the adoption of Solaris and Sun Studio.
Download Sun Studio 11 today:
http://developers.sun.com/sunstudio/download
Thanks!
/kso
PS. See what these 2 guys think of Sun Studio 11:
(apologies to those who are unable to view real streams)
http://webcast-east.sun.com/ramgen/archives/VIP-2199/VIP-2199_01_300.rm

In reading the click-thru license, I came across the following in section 5(i):
"Software may contain programs that perform automated collection of system data and/or automated software updating services. System data collected through such programs may be used by Sun, its subcontractors, and its service delivery partners for the purpose of providing you with remote system services and/or improving Sun's software and systems."
Does this mean that the software will phone home to the 'mother ship' and report on my utilization? It seems to be worded in such a way as to be able to send my hardware configuration and other things that I may not want to share with Sun.

Sun Studio 12 U 1 and __asm__ __volatile__

Hi,
with SS12U1 on OpenSolaris/x86, is there a way to build C++ code that uses the '__asm__ __volatile__' statements directly or will I have to rewrite the assembly parts?
From what I gathered searching the web, it's the second option, but perhaps there's something obvious I overlooked :-)
TIA
hajma

You don't say exactly what problem you are having, but it sounds like you have run into bug 6607624, where the gcc-style code
__asm__ __volatile__is not recgonized. The problem has been fixed in the development compiler (which won't be available for some time), but is not currently scheduled for fixing in SS12u1.
Please file a bug repor on the C++ compilert at [http://bugs.sun.com], and we'll add your information to the existing report. That should improve the chances of it appearing in a patch to SS12u1.

How to generate gdb compatible .o for CMT using Sun Studio C compiler?

Hello,
we've been working on a joint project for telco bearer plane applications on CMT.
We started the project using gcc for Sparc and we switched to Sun Studio compiler when we hit some bugs in gcc (optimized mode was not completely stable). The switch took a few weeks due to syntax differences and toolchain option changes.
With Sun Studio we got a double digit percent performance improvement, so Sun Studio proved more stable and faster than gcc.
To debug programs we require gdb, because the Telco customers are more familiar with it. The problem is that Sun Studio generates object files which are not compatible with gdb.
Our main requirement is to be able to generate gdb compatible object files using Sun Studio compiler.
We checked this link:
http://cooltools.sunsource.net/gcc/ReleaseNotes.html
but this seems to be a variant of gcc. At this point we cannot switch compiler because of the performance and stability issues mentioned above and because it will take a few weeks to months to switch.
We have two questions:
1) Is there a way to generate gdb compatible object files using Sun Studio 11?
2) If not, is this funcionality going to be available in a future release of Sun Studio and what is the time frame?
Thanks for your help.
Marco Zandonadi
Teja Technologies

The undefined symbol is in the C++ runtime support library that is part of Solaris. Probably you have an out-fo-date version of the libraries.
You can get current patches from the Sun Studio patch page:
http://developers.sun.com/prodtech/cc/downloads/patches/index.html
From the page for your version of WorkShop or Sun Studio, select the C++ Runtime Library patch for the version of Solaris that your are running. While you are at it, you can get the current compiler patches as well.
If patching the runtime libraries does not fix the problem, let me know, and also show the exact command lines that you use for compiling and linking the program.

Compilation error while building boost 1_44_0 on Solaris (Sun Studio 10)

Hi All, I am trying to build boost version 1_44_0 on Solaris.The Solaris box has Sun Studio 10 installed.
The compiler details are
bash-2.05$ CC -V
CC: Sun C++ 5.7 2005/01/07
I am using the following command to build boost libraries
*bash-2.05$ bjam --build-dir=/export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build-boost toolset=sun stage*
But i get the below compilation errors, not even one of the projects build
sun.compile.c++ /export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build-boost/boo
st/bin.v2/libs/iostreams/build/sun/release/stdlib-sun-stlport/threading-multi/fi
le_descriptor.o
Notice: The Early Access serial number will expire in -7 days.
In order to purchase the product, visit http://www.sun.com/forte/buy.html
or contact your Forte Tools reseller.
"libs/iostreams/src/file_descriptor.cpp", line 352: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 355: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 360: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 380: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 385: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 393: Error: Using static_cast to
convert from boost::iostreams::file_descriptor_flags to boost::iostreams::detail
::file_descriptor_impl::flags not allowed.
6 Error(s) detected.
"CC" -library=stlport4 -xO4 -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DB
OOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o
"/export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build-boost/boost/bin.v2/libs/
iostreams/build/sun/release/stdlib-sun-stlport/threading-multi/file_descriptor.o
" "libs/iostreams/src/file_descriptor.cpp"
...failed sun.compile.c++ /export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build
-boost/boost/bin.v2/libs/iostreams/build/sun/release/stdlib-sun-stlport/threadin
g-multi/file_descriptor.o...
sun.compile.c++ /export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build-boost/boo
st/bin.v2/libs/iostreams/build/sun/release/stdlib-sun-stlport/threading-multi/ma
pped_file.o
Notice: The Early Access serial number will expire in -7 days.
In order to purchase the product, visit http://www.sun.com/forte/buy.html
or contact your Forte Tools reseller.
"./boost/type_traits/is_array.hpp", line 41: Error: Multiple declaration for boo
st::is_array.
"./boost/type_traits/is_array.hpp", line 42: Error: Multiple declaration for boo
st::is_array.
"./boost/type_traits/is_array.hpp", line 43: Error: Multiple declaration for boo
st::is_array.
"./boost/type_traits/is_array.hpp", line 44: Error: Multiple declaration for boo
st::is_array.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 95: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1> is dependent on
another argument.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 95: Error: Partial s
pecialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 112: Error: Partial
specialization parameter F is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 172: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1, boost::mpl::aux
::P2> is dependent on another argument.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 172: Error: Partial
specialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 189: Error: Partial
specialization parameter F is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 254: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1, boost::mpl::aux
::P2, boost::mpl::aux::P3> is dependent on another argument.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 254: Error: Partial
specialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 271: Error: Partial
specialization parameter F is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 339: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1, boost::mpl::aux
::P2, boost::mpl::aux::P3, boost::mpl::aux::P4> is dependent on another argument
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 339: Error: Partial
specialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 357: Error: Partial
specialization parameter F is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 427: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1, boost::mpl::aux
::P2, boost::mpl::aux::P3, boost::mpl::aux::P4, boost::mpl::aux::P5> is dependen
t on another argument.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 427: Error: Partial
specialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 445: Error: Partial
specialization parameter F is not used in the arguments.
"libs/iostreams/src/mapped_file.cpp", line 441: Error: Could not find boost::sha
red_ptr<boost::iostreams::detail::mapped_file_impl>::shared_ptr(boost::iostreams
::detail::mapped_file_impl*) to initialize pimpl_.
20 Error(s) detected.
Am i missing something? I will appreciate your input's.
Regards,
solarisneo

C++ 5.7 will not give good results building Boost.
Support for boost began with C++ 5.9 (Sun Studio 12), but you will get better results using the current release, Sun Studio 12 update 1, and better still with the upcoming release, Oracle Solaris Studio 12.2.

Sun Studio 12 Update1 and OpenMP

Hi guys,
I was using the Sun Studio 12 with OpenMP and everything was OK. So I decide to download the update 1 (which is OpenMP 3.0 full compliance), however I am getting linking error.
Below is the message:
Undefined first referenced
symbol in file
__mt_MasterFunction_cxt_ build/Debug/SunStudio_12.1-Solaris-x86/a1.o
I look into my libmtsk.so libraries and I could see that __mt_MasterFunction_cxt_ really does not exist.
So I believe this is a bug on Sun Studio 12 Update 1 that didn't install the last library. Anyway, I am try to find out where to get this library or any patch to it. I did try to get the patch 120754. However the site is pointing that I has no support contract. What is true just because I am a student, and I am just learning things for now...:-)
Hope someone can help me with that..
Thanks and Regards

I cannot download any patch because I do not have any support contract.Last time I tried, Solaris patches were free, at least those related to compiler components.
Byt the way, I rarely install the product myself, but I had an impression that Solaris version comes together
with patches, which are intended to be installed right upon the installation.
I'm sorry for the lost hours of precious time, but that seems to be more like your navigational error,
rather than the intentional attempt from Sun to decieve you.
Believe me or not, we made Sun Studio free because we want developers to use it, not because
we hope to catch you offguard and cut some money.
I should get opensolaris if I want a "linux like license and support"And that is true.
If you do not like the way Solaris patches are managed (and, many think that it is a mess) you might better like Opensolaris.
You also might want to try Linux version, it is as close to Solaris version functionality-wise as possible.
I will just uninstall my sun studio 12 update 1 and go back to the sun studio 12 (where no patches are needed to run the openmp 2.5).Sun Studio 12 got no interface change thus no patches were needed to run OpenMP 2.5 as soon as you have libmtsk.so installed.
Quite contrary, SS12u1 got OpenMP 3.0, which is substantially different to OpenMP 2.5 and that warranted interface change in runtime support
(libmtsk.so).
Trying to create "partial open source" things is not that good. First, it is not open source yet :-), it is just free.
Then, if we would do partial thing (which is not that bad per se, surely depending on how you do it), that would definitely be written in caps all around.
And broken functionality is definitely not the way Sun does its business.
regards,
__Fedor.

Error in compiling boost example program using sun studio 12

I am trying to compile the below example program from boost using sun studio 12 C++ compiler.
#include <boost/interprocess/shared_memory_object.hpp>
#include <boost/interprocess/mapped_region.hpp>
#include <cstring>
#include <cstdlib>
#include <string>
int main(int argc, char *argv[])
using namespace boost::interprocess;
if(argc == 1)
{ //Parent process
//Remove shared memory on construction and destruction
struct shm_remove
shm_remove() { shared_memory_object::remove("MySharedMemory"); }
~shm_remove(){ shared_memory_object::remove("MySharedMemory"); }
} remover;
//Create a shared memory object.
shared_memory_object shm (create_only, "MySharedMemory", read_write);
//Set size
shm.truncate(1000);
//Map the whole shared memory in this process
mapped_region region(shm, read_write);
//Write all the memory to 1
std::memset(region.get_address(), 1, region.get_size());
//Launch child process
std::string s(argv[0]); s += " child ";
if(0 != std::system(s.c_str()))
return 1;
else
//Open already created shared memory object.
shared_memory_object shm (open_only, "MySharedMemory", read_only);
//Map the whole shared memory in this process
mapped_region region(shm, read_only);
//Check that memory was initialized to 1
char mem = static_cast<char>(region.get_address());
for(std::size_t i = 0; i < region.get_size(); ++i)
if(*mem++ != 1)
return 1; //Error checking memory
return 0;
Using the below command :
CC -c 1.cpp -I/home/syogacha/satish/boost_1_43_0 -library=stlport4
"/home/syogacha/satish/boost_1_43_0/boost/interprocess/shared_memory_object.hpp", line 284: Error: The function "shm_open" must have a prototype.
"/home/syogacha/satish/boost_1_43_0/boost/interprocess/shared_memory_object.hpp", line 307: Error: The function "shm_unlink" must have a prototype.
"/home/syogacha/satish/boost_1_43_0/boost/interprocess/mapped_region.hpp", line 549: Error: Formal argument 1 of type char* in call to shmdt(char*) is being passed void*.
3 Error(s) detected.
I even tried to include sys/mman.h but got the same compilation errors.
Do we need to take care of few other specific things while using boost headers.
Thanks in advance ...

Hope this helps....
#include <sys/mman.h>
#include <boost/interprocess/shared_memory_object.hpp>
#include <boost/interprocess/mapped_region.hpp>
#include <cstring>
#include <cstdlib>
#include <string>
#include <iostream>
#include <iterator>
int main(int argc, char *argv[])
{      //main
        using namespace boost::interprocess;
        if(argc == 1)
        { //Parent process
                //Remove shared memory on construction and destruction
                struct shm_remove
                        shm_remove() { shared_memory_object::remove("MySharedMemory"); }
                        ~shm_remove(){ shared_memory_object::remove("MySharedMemory"); }
                } remover;
                //Create a shared memory object.
                shared_memory_object shm (create_only, "MySharedMemory", read_write);
                //Set size
                shm.truncate(1000);
                //Map the whole shared memory in this process
                mapped_region region(shm, read_write);
                //Write all the memory to 1
               std::memset(region.get_address(), 1, region.get_size());
                //Launch child process
                std::string s(argv[0]); s += " child ";
                if(0 != std::system(s.c_str()))
                return 1;
        else
                //Open already created shared memory object.
                shared_memory_object shm (open_only, "MySharedMemory", read_only);
                //Map the whole shared memory in this process
                mapped_region region(shm, read_only);
                //Check that memory was initialized to 1
                char *mem = static_cast<char*>(region.get_address());
                for(std::size_t i = 0; i < region.get_size(); ++i)
                if(*mem++ != 1)
                return 1;   //Error checking memory
        return 0;
}

BOOST and Sun Studio 10

C++ 5.7 in Sun Studio 10 now compiles most of BOOST 1.32.0, when the compiler is updated with the current patches from
http://developers.sun.com/prodtech/cc/downloads/patches/ss10_patches.html
Two known bugs remain, and should be fixed in a future patch.
Some of the BOOST compilation failures are due to errors in the BOOST configuration for Sun C++. We have submitted corrections to the BOOST site, and we hope all of them will be included in version 1.33.0.
In the mean time, you can apply the following corrections to version 1.32.0:
1. Get this correction from the BOOST bug tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=1155439&group_id=7586&atid=107586
2. Also get this correction from the BOOST bug tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=1165980&group_id=7586&atid=107586
3. Edit build.sh according to these diffs: *** build.sh.orig     Fri Mar 18 06:09:44 2005
--- build.sh     Fri Mar 18 06:41:07 2005
*** 150,160 ****
      sunpro)
!     if test -r /opt/SUNWspro/bin/cc ; then
          BOOST_JAM_TOOLSET_ROOT=/opt/SUNWspro/
      fi
!     if test -r $BOOST_JAM_TOOLSET_ROOTbin/cc ; then
!         export PATH=$BOOST_JAM_TOOLSET_ROOTbin:$PATH
      fi
      BOOST_JAM_CC=cc
--- 150,161 ----
      sunpro)
!     if test -z "${BOOST_JAM_TOOLSET_ROOT}" -r /opt/SUNWspro/bin/cc ; then
          BOOST_JAM_TOOLSET_ROOT=/opt/SUNWspro/
      fi
!     if test -r ${BOOST_JAM_TOOLSET_ROOT}bin/cc ; then
!         PATH=${BOOST_JAM_TOOLSET_ROOT}bin:${PATH}
!         export PATH
      fi
      BOOST_JAM_CC=cc
      ;;

Here is a small but complete test program, together with the command line of the compiler. This is the patch level of the compiler we use here:
CC: Sun C++ 5.7 Patch 117830-02 2005/03/30Test program (graph_test.cpp):
#include <iostream>                  // for std::cout
#include <utility>                   // for std::pair
#include <algorithm>                 // for std::for_each
#include <boost/graph/graph_traits.hpp>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/dijkstra_shortest_paths.hpp>
using namespace boost;
int main(int,char*[])
enum { A, B, C, D, E, N };
const int num_vertices = N;
const char* name = "ABCDE";
typedef adjacency_list<vecS, vecS, bidirectionalS> Graph;
Graph g(num_vertices);
typedef graph_traits<Graph>::vertex_iterator vertex_iter;
std::pair<vertex_iter, vertex_iter> vp;
vp = vertices(g); /** Error **/
return 0;
}Command line:
CC -I./include/boost -v graph_test.cpp
###     command line files and options (expanded):
### -I/export/rpms/401/tools/inst/include/boost -v graph_test.cpp
### CC: Note: NLSPATH = /export/home2/SUNs10/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/export/home2/SUNs10/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
/export/home2/SUNs10/SUNWspro/prod/bin/ccfe -y-o -ygraph_test.o -I/export/rpms/401/tools/inst/include/boost -y-fbe -y/export/home2/SUNs10/SUNWspro/prod/bin/fbe -y-xarch=generic -y-verbose -O0 -ptf /tmp/00299%1.%2 -ptx /export/home2/SUNs10/SUNWspro/prod/bin/CC -ptk "-I/export/rpms/401/tools/inst/include/boost -v -xs " -D__SunOS_5_8 -D__SUNPRO_CC=0x570 -Dunix -Dsun -Dsparc -D__sparc -D__sparcv8plus -D__unix -D__sun -D__BUILTIN_VA_ARG_INCR -D__SVR4 -D__SUNPRO_CC_COMPAT=5 -D__SUN_PREFETCH -xdbggen=no%dwarf2+stabs -y-s -xdbggen=incl -y-xmemalign=8i -I-xbuiltin -xldscope=global -instlib=/export/home2/SUNs10/SUNWspro/prod/lib/libCstd.a -I/export/home2/SUNs10/SUNWspro/prod/include/CC/Cstd -I/export/home2/SUNs10/SUNWspro/prod/include/CC -I/export/home2/SUNs10/SUNWspro/prod/include/CC/rw7 -I/export/home2/SUNs10/SUNWspro/prod/include/cc -y-comdat graph_test.cpp -s /tmp/ccfe.00299.0.s >&/tmp/ccfe.00299.1.err
rm /tmp/ccfe.00299.0.s
/export/home2/SUNs10/SUNWspro/prod/bin/stdlibfilt -stderr </tmp/ccfe.00299.1.err
"graph_test.cpp", line 22: Error: Could not find a match for boost::vertices<boost::T>(boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::no_property, boost::no_property, boost::no_property, boost::listS>) needed in main(int, char**).
1 Error(s) detected.
rm /tmp/ccfe.00299.1.err
rm graph_test.oAny help would be greatly appreciated! If you need any more information, please let me know.
Thanks in advance,
Andreas

Future support for C++0x in Sun Studio

I've recently been having to defend my choice of using the sun studio compiler against several gcc advocates here in the office. The one reasonable issue they keep bringing up is when the upcoming C++0x (more like C++1x or even C++2x at the pace the standards committee is operating at) features will be available in complete fashion in sun studio. They say, and I have to begrudgingly agree, that judging by the amount of time it took studio to support boost (template templates, certain partial template specializations, etc), there could be a long delay between the release of gcc's C++0x support and that of studio's.
I understand that many of the new features of C++0x, even from initial glance, appear to be quite complicated, especially lambda functors and their associated []/auto return types, variadac template parameters and class concept checking. In addition, I understand gcc has an unfair advantage so to speak since it is being used as the test bed for many of the committee proposal submitter's proof-of-concept implementations (the variadic template parameter feasibility implementation written for gcc comes to mind).
Could a developer please assuage my fears and inform me that the studio team has a roadmap/timeframe in place to release a studio that fully supports the new language-level features in a reasonably competitive time frame? It apparently will be the responsibility of the STLPort team to essentially copy many of boost's libraries (shared_ptrs, random numbers, type_traits) and rename them and move them to the std namespace and also supply the new unordered<> containers, to name a few.
I for one can't wait until boost::mpl, boost::fusion, boost::format and others are all reduced from 10's of 1000's of lines of pre-processor generated crufty template definitions to a single variadic template declaration. Also, I won't feel quite so willfully derelict to efficient code every time i bust out an std::for_each and drop in a boost::bind generated functor and instead can use a lambda function with the various efficiency gains ranging from direct referencing to the stack variables passed in as the closure arguments to the ability for the compiler to actually inline the body of the lambda function where appropriate.
I'm in no way trying to accuse you compiler developers of being slow to implement features, but just would like to be assured that there is nothing to worry about and there is a plan and current work being done on the required features. I know it's still a couple of years off, but I personally can't wait to replace hundreds of lines of boost::bind() calls with their more efficent lambda equivalent, and in addition clean up interfaces that could have used boost::bind if it weren't for the unacceptable overhead introduced often executed blocks of code.
Thanks,
Chris Knight - Faithful sun studio user through at least 2 major name changes and since at lest when it was called Forte 4.2 and RougeWave and classicIO libraries roamed the earth in vast quantities.
P.S. I truly fear that the other 3 major compilers (gnu, intel, ms) will be out the door with C++0x in around the same time and boost will then willingly drop support for the sun compiler if it doesn't support the required language features at that time as they had no problem not supporting studio at all until Studio 12 so I'm sure as soon as the 3 compilers they run nightly tests with support it, they'll be just as eager to
make use of the new features as I am.
This leaves someone who has based their entire system on Solaris + SunStudio + Boost in a potentially undesirable situation. Solaris is far too stable and Linux to ever-changing to ever consider Linux as a platform for critical systems yet the idea of running g++ on Solaris w/ gcc's propensity to change their ABI on a weekly basis gives me immediate heartburn.
Thanks again.

You raise some very good points, and believe me, we are even more aware of them than you are!
Short answer: We are planning to bring out a compiler conforming to C++0X in a timely fashion.
Longer answer:
Right now, we are working on providing binary compatibility with g++ as an option in the next compiler release. When we are done, you will be able to use g++ headers with Sun C++, and link the code with binaries created by g++. The first implementation will be on Linux. (Which versions of g++ and which versions of Linux? Stay tuned.)
Implementing all the new features of C++0X will require a re-design of parts of the compiler front end. The current compiler organization does not support "concepts", for example. (We've been looking for an excuse to re-design the front end for a while, and C++0x is not just an excuse -- it's a requirement.) With the g++ ABI work done, we'll ready to start the re-design, and begin to implement C++0x features.
We won't release an official (stable, fully-supported) product with C++0X features until the standard is final. Until then, any feature could change in unpredictable ways. We got caught by that problem with C++ 4.2 and C++98 -- we implemented what we thought were final features that changed dramatically after we released the compiler. We won't do that again. Compiler stability is one of our most important considerations.
Beginning some time next year, we expect to have Express releases with some C++0X features. Express releases are our way of providing compilers with experimental features that might not be stable yet. It gives our customers a chance to try them out and provide feedback before they become part of a stable release. That is to say, a feature flagged as experimental is subject to change, and compatibility with other Express or official releases is not guaranteed. We can therefore fix bugs and catch up with late changes in the Standard as necessary.
We have not yet done all the planning for our C++0X compiler, so I can't give you any estimates about specific feature availability and time frames. When we are farther along, we'll post the road map on a public site, and I'll announce it here.
Steve Clamage
Sun C++ Team

GTK in Sun Studio project (question)

I'm new to Sun Studio. My background is 22 years c/c++ non-unix development (embedded systems & Windows application development).
I'm trying to write a GUI based c++ app for Solaris. I know this is a complete newbie question. Any help will be GREATLY appreciated.
Here's my question/issue: I cannot seem to include <gtk.h>. I've installed every GTK/ GTKMM package I can find. Building/deploying any project that does not use GTK is fine. I cannot for the life of me figure out how to build a GTK app. Even the GtkFreeway example app for Sun Studio fails to compile at #include <gtk.h>.
So, how do I set up my environment to include gtk headers and link with the appropriate libraries.
Thanks in advance,
Mike

You can use the IDE. Add the path to the gtk.h include directory in the compiler option dialog.
For example, if gtk.h is in /opt/gtk/include, add /opt/gtk/include to the list of -I options.
If the error you get is
Could not open include file "gtk.h"
it's due to the missing path.
If you get some other error, please post the error output.
Your experience with <> and "" for include directives is misleading. You can make incorrect inferences due to not testing every possible combination of headers locations and #include directives..
The C++ standard says the <> form is required for standard headers. It goes on to say that the search method for the "" and <> forms is implementation-defined. The search method for Sun C++ is described in the C++ Users Guide
[http://docs.sun.com/app/docs/doc/820-7599/bkaso?a=view]
The details of lookup vary only slightly among modern compilers. If you use <> for system headers and "" for project headers, you should expect to get the right result. The <> form can prevent local directories from being searched, which is appropriate for system includes, but not for project includes.

Can I purchase only PART of Sun Studio 10 ???

I am a long-time UnixWare Developer who is contemplating switching myself and my clients to Solaris 10. Solaris is free of course, but Sun Studio is very expensive -- about $3000 -- which is over 10 times more than I paid for the UnixWare Development Kit.
The only thing I really need is the C++ compiler and supporting libraries, and programs like "make", etc. Even though I have produced several hundred thousand lines of code, I haven't used a debugger in years, and don't need an IDE.
Can just PARTS of Sun Studio 10 be purchased independently, or is it "all or nothing"? I would be more likely make the move if I didn't have to invest in so much overkill. Components beyond the basics might hold an attraction as a separate -- and later -- investment.
Thanks,
David H. Braun (owner/developer, MultiTask ComputerWorks)
P.S. -- If this is not currently possible, could someone pass this on as a suggestion to higher authorities at Sun. Enabling smaller quantum leaps always increases the likelihood a transition will take place.

David,
Please send your question to [email protected]
Thank you,
tom

Studio 12: C compiler generates bad code with -m64 -KPIC -xO2

Hello,
after upgrading my Solaris 10/x64 machine from Studio 11 to Studio 12 some problems were fixed, but others came up; like this one:
I have a code snippet that obviously causes the C compiler to generate wrong code if compiled with options -m64 -KPIC -xO2. If any of these options are missing, it runs fine. Here's the example code:
#include <stdio.h>
#include <strings.h>
static int do_something() { return 0; }
static int foo() {
    fprintf(stderr, "\n!! BUG: BAD CODE! unexpected function call foo()!\n\n");
    return 222;
static int bar() {
    fprintf(stdout, "\nOK: bar() called\n\n");
    return 0;
static const struct {
    const char* name;
    int (*func)();
    int flag;
} tab[] = {
    { "foo", &foo, 0 },
    { "bar", &bar, 0 },
    { 0, 0, 0 }
int main(int argc, const char** argv) {
    int i;
    for (i=0; tab.name; i++) {
if( strcmp(tab[i].name, "bar") == 0 ) {
if(tab[i].flag) {   /* not reached */
if(!do_something()) {
return 2;
return (*tab[i].func)();
return 1; /* not reached */
Many lines seem to be bogus, but they are actually needed to reproduce the problem.
This is what happens:# cc -m64 -KPIC -xO2 bug.c && ./a.out ; echo $?
!! BUG: BAD CODE! unexpected function call foo()!
222
If I compile with debugging information (-g), I get expected behavior, which is:# cc -m64 -KPIC -g bug.c && ./a.out ; echo $?
OK: bar() called
0
While creating the test case I've also seen SIGSEGV at runtime in the bug case - which is probably due to a wrong calculated function address for jmp (just guessing).
Does anyone know if this is a known bug?
Any help is appreciated.
The rest of this posting is information about my system and Studio 12 patch level:# uname -a
SunOS v20 5.10 Generic_137112-08 i86pc i386 i86pc
# /usr/SUNWspro/bin/version
Machine hardware: i86pc
OS version: 5.10
Processor type: i386
Hardware: i86pc
The following components are installed on your system:
Sun Studio 12
Sun Studio 12 C Compiler
Sun Studio 12 C++ Compiler
Sun Studio 12 Tools.h++ 7.1
Sun Studio 12 C++ Standard 64-bit Class Library
Sun Studio 12 Garbage Collector
Sun Studio 12 Fortran 95
Sun Studio 12 Debugging Tools (including dbx)
Sun Studio 12 IDE
Sun Studio 12 Debugger GUI
Sun Studio 12 Performance Analyzer (including collect, ...)
Sun Studio 12 X-Designer
Sun Studio 12 VIM editor
Sun Studio 12 XEmacs editor
Sun Studio 12 Performance Library
Sun Studio 12 LockLint
Sun Studio 12 Building Software (including dmake)
Sun Studio 12 Documentation Set
Sun Studio 12 /usr symbolic links and GNOME menu item
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_i386 Patch 124864-08 2008/10/16
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_i386 Patch 127002-04 2008/04/16
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_i386 Patch 124873-06 2008/08/20
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_i386 Patch 126996-04 2008/09/03
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_i386 Patch 126504-01 2007/07/19

I'm watching Bug ID: [6774287|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6774287] for quite a while and it seems to be fixed some time ago (State: 8-Fix Available, bug). Does anybody know if the fix made it in some officially available SunStudio 12 C compiler (backend) patch already? I'm using this SS12 patch-level meanwhile:
# /usr/SUNWspro/bin/version
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_i386 Patch 124868-08 2008/11/25
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_i386 Patch 124864-09 2008/12/16
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_i386 Patch 127002-05 2008/10/21
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_i386 Patch 124873-06 2008/08/20
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_i386 Patch 126996-04 2008/09/03
version of "/usr/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_i386 Patch 126504-01 2007/07/19

Using boost::thread with Sun Studio C++ gives error

Hi,
I'm trying to compile a code which uses the boost thread library, but I get the following error:
CC -library=stlport4 -features=tmplife -features=tmplrefstatic -mt -c -o t t.cpp
"/opt/boost/include/boost/thread/pthread/mutex.hpp", line 142: Error: The function "pthread_mutex_timedlock" must have a prototype.
"/opt/boost/include/boost/thread/pthread/mutex.hpp", line 142: Error: The function "pthread_mutex_timedlock" must have a prototype.
"/opt/boost/include/boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost::thread>).
"/opt/boost/include/boost/thread/pthread/recursive_mutex.hpp", line 179: Error: The function "pthread_mutex_timedlock" must have a prototype.
"/opt/boost/include/boost/thread/pthread/recursive_mutex.hpp", line 179: Error: The function "pthread_mutex_timedlock" must have a prototype.
5 Error(s) detected.
make: *** [t] Error 5the sample source code in question here just a single include:
#include <boost/thread.hpp>This is with boost 1.40.0. I wonder what I'm doing wrong..
Akos

OK, I tried latest version of CC from Sun Studio 12 update 1 and can say that
- the error about constructor not being accessible is Sun C++ compiler "feature" (only called feature because it existed for so long) that allows binding of rvalues to non-const references; this "feature" will probably be turned off in the next release. It can't be changed in a patch because client's code might rely on it.
- the other errors are also not Boost-specific: the result of incompatibility of Linux headers and Sun C++ compiler; more thorough investigation is due, but in the past we had several problems like this. This particular can be solved by adding
-D_GNU_SOURCE to compile line.

Sun Studio 12 CC compiler and gcc libraries

Similar Messages

Maybe you are looking for