Problem in compilation using Sun Studio 11

Hello,
We are migrating from a Solaris 8 to a Solaris 10 OS. At the same ttime we are also migrating from Ingres 2.6 to Ingres 2006. As a part of the creation of teh development environment, we are recompiling all the codes on teh new OS. WE have installed teh Sun Studio 11 compiler for this purpose. When compiling some C codes, we are getting the following error:
"am_xxxxxxxx.c", line 2596: warning: statement not reached
"am_xxxxxxxx.c", line 2778: undefined symbol: i8
"am_xxxxxxxx.c", line 2778: syntax error before or at: )
"am_xxxxxxxx.c", line 2858: undefined symbol: i8
"am_xxxxxxxx.c", line 2858: syntax error before or at: )
"am_xxxxxxxx.c", line 2889: warning: implicit function declaration: IIresnext
"am_xxxxxxxx.c", line 2891: warning: statement not reached
"am_xxxxxxxx.c", line 2920: warning: statement not reached
"am_xxxxxxxx.c", line 2931: undefined label: IIfdF1
"am_xxxxxxxx.c", line 2931: undefined label: IIosl9139
"am_xxxxxxxx.c", line 2931: undefined label: IIfdE1
"am_xxxxxxxx.c", line 2931: cannot recover from previous errors
cc: acomp failed for am_xxxxxxxx.c
The command used for compiling is :
cc -xarch=generic64 am_xxxxxxxx.c
We have exported teh following:
LD_LIBRARY_PATH_64=/usr/sfw/lib/sparcv9:/usr/local/lib/sparcv9:/usr/lib/sparcv9:/usr/openwin/lib/sparcv9:/usr/dt/lib/sparcv9:/opt/SUNWspro/lib/v9:/opt/SUNWspro/lib/v9:/eu/ingad/ingres/lib:/opt/oracle/lib:/usr/lib:/usr/ucblib:/usr/openwin/lib:/opt/SUNWspro/lib/:/opt/lib/cobol/coblib
LD_LIBRARY_PATH=/opt/SUNWspro/lib/v9:/eu/ingad/ingres/lib:/eu/ingad/ingres/lib:/opt/oracle/lib:/usr/lib:/usr/ucblib:/usr/openwin/lib:/opt/SUNWspro/lib/:/opt/lib/cobol/coblib
CXXFLAGS=-fast -xarch=v9b
CFLAGS=-fast -xarch=v9b
LDFLAGS=-L/usr/sfw/lib/sparcv9 -L/usr/lib/sparcv9 -R/usr/sfw/lib/sparcv9 -R/usr/lib/sparcv9
We are struggling with this issue for the last one week. Can someone please help me with this issue?
Could this be because the 64 bit library files are not installed? Please help.
Aneesha

The LD_LIBRARY_PATH environment variables determine where the runtime loader looks for shared libraries when you run an application. It is unlikely to be the source of compile-time errors.
I suspect that doing two major changes at the same time has resulted in undefined names and other problems, probably due to missing or incorrect header inclusion. If possible, make one change at a time, either compile the old code on the new OS, or the new code on the old OS, and get that to work first.
Check the Ingress documentation to see if you need to make source code changes when upgrading, and follow any recommendations there. You might also need to take up this problem with Ingress tech support.
Regarding LD_LIBRARY_PATH, the best advice is usually "don't set it at all". For more on this topic, see this article:
http://blogs.sun.com/rie/entry/tt_ld_library_path_tt
Just to eliminate this as a possible build problem, try removing LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 from your environment when building the program. Then modify the build process to set the executable runpath (-R option) to include the Ingress or Oracle libraries that need to be searched. You don't normally want to point into /usr/lib or into the compiler installation area.

Similar Messages

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.

Binary compatibility problems using Sun Studio 12

I'm working in a project that uses Orbix [1] third-party libraries. I have installed the Sun Studio 12 on Solaris 10 SPARC but I have got some strange segfault problems (the exactly same code works fine in a Linux box - using g++). I read the 1.4 section of Sun Studio 12 C++ Userguide [2] but I have a doubt:
Is there no way to compile my code using Sun Studio 12 using shared libraries compiled against earlier Sun Studio C++ compiler versions (like Sun Studio 8 or some version before Sun Studio 11)?
I think my problem is related to the fact that Orbix team used Sun Studio 8 as some notes found in their headers indicate:
"IONA Technologies ART IDL Compiler POA C++ Generator asp 6.3.3 SunOS 5.8 CC_5.5 2008/06/13 21:04:37 EDT"
A secondary question: Is CC 5.5 present in Sun Studio 8, right?
Can anyone help me? Every tips are welcome :) Thanks in advance!
[1] http://web.progress.com/en/orbix/orbix_standard.html
[2] http://docs.sun.com/app/docs/doc/820-7599/6nirkt6f7?a=view

AmadeuBarbosa wrote:
I'm working in a project that uses Orbix [1] third-party libraries. I have installed the Sun Studio 12 on Solaris 10 SPARC but I have got some strange segfault problems (the exactly same code works fine in a Linux box - using g++). I read the 1.4 section of Sun Studio 12 C++ Userguide [2] but I have a doubt:I don't think 1.4 Binary Compatibility Verification applies in your case. It's referring to processor capability to execute certain (new) instructions; if your third-party libraries were compiled a while ago, it's highly unlikely they use instructions not implemented by the processor you have.
Is there no way to compile my code using Sun Studio 12 using shared libraries compiled against earlier Sun Studio C++ compiler versions (like Sun Studio 8 or some version before Sun Studio 11)?Generally speaking, any library compiled with older Sun Studio C++ compiler is supposed to be compatible with any library or executable compiled with newer version provided that all parties did everything right. For example, that third-party libraries should not be statically linked with C++ run-time support libraries; your executable should be linked with latest compiler driver (CC) so that it records correct dependencies on support libraries.
Of course, there could be (and actually are) compiler bugs standing in the way of compatibility. Some of them can be fixed, some - like demangler issue described in http://docs.sun.com/source/820-4155/c++.html - can't. There is no easy way to tell if you hit a compiler bug or bulding/linking issue, or bug in the code that was previously unseen.
I think my problem is related to the fact that Orbix team used Sun Studio 8 as some notes found in their headers indicate:
"IONA Technologies ART IDL Compiler POA C++ Generator asp 6.3.3 SunOS 5.8 CC_5.5 2008/06/13 21:04:37 EDT"Yes, looks like it was compiled by 5.5, which is part of Sun Studio 8
>
A secondary question: Is CC 5.5 present in Sun Studio 8, right?That's correct.

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;
}

Compiling C++ using Sun Studio 11

Hi,
I have downloaded and installed "IBM Message Service client for C/C++" (in Solaris 5.8) to publish messages to Websphere MQ Topics using C++ programs. The IBM installation comes with a compiled version of the sample programs and I am able to execute them successfully using Sun studio 11's C++ compiler. But when I try to compile these sample programs , it throws the following exception.
mqm$ CC SampleConsumerCPP.cpp
"SampleConsumerCPP.cpp", line 36: Error: Could not open include file<xms.hpp>.
"SampleConsumerCPP.hpp", line 39: Error: Could not open include file<helperfunctions.h>.
"SampleConsumerCPP.hpp", line 52: Error: xmsVOID is not defined.
"SampleMsgListener.hpp", line 44: Error: xms is not defined.
"SampleMsgListener.hpp", line 44: Error: MessageListener is not defined.
"SampleMsgListener.hpp", line 55: Error: Type name expected instead of "xmsVOID".
"SampleMsgListener.hpp", line 55: Error: "virtual" is not allowed here.
"SampleMsgListener.hpp", line 55: Error: Identifier expected instead of "const".
"SampleMsgListener.hpp", line 55: Error: Use ";" to terminate declarations.
"SampleMsgListener.hpp", line 56: Error: Use ";" to terminate declarations.
"SampleMsgListener.hpp", line 56: Error: "," expected instead of "displayMsg".
"SampleMsgListener.hpp", line 62: Error: Use ";" to terminate declarations.
"SampleMsgListener.hpp", line 62: Error: Type name expected instead of "xmsVOID".
"SampleMsgListener.hpp", line 63: Error: Type name expected instead of "xmsINT".
"SampleMsgListener.hpp", line 63: Error: Identifier expected instead of "const".
"SampleMsgListener.hpp", line 63: Error: Multiple declaration for const.
"SampleMsgListener.hpp", line 63: Error: Use ";" to terminate declarations.
"SampleMsgListener.hpp", line 64: Error: Use ";" to terminate declarations.
"SampleMsgListener.hpp", line 64: Error: Type name expected instead of "xmsVOID".
"SampleMsgListener.hpp", line 65: Error: Type name expected instead of "xmsINT".
"SampleMsgListener.hpp", line 65: Error: Identifier expected instead of "const".
"SampleMsgListener.hpp", line 65: Error: Multiple declaration for const.
"SampleMsgListener.hpp", line 65: Error: Use ";" to terminate declarations.
"SampleMsgListener.hpp", line 67: Error: Use ";" to terminate declarations.
"SampleMsgListener.hpp", line 73: Error: Type name expected instead of "xmsINT".
Compilation aborted, too many Error messages.
The compiler does not recognize the "make" command either.
Find below my PATH settings.
"/tools/java/j2sdk1.4.2_08/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/data/sunstudio10/SUNWspro/bin:/opt/mqm/java/bin:/usr/openwin/bin:/data/mqapi/tools/cpp/include:/data/mqapi/tools/samples/common:/data/mqapi/lib"
where /data/mqapi contains the XMS installation.
Any pointers to solve this issue will be highly appreciated.
Thanks,
Meeraa

Hi,
I have downloaded and installed "IBM Message Service
client for C/C++" (in Solaris 5.8) ...
mqm$ CC SampleConsumerCPP.cpp
"SampleConsumerCPP.cpp", line 36: Error: Could not
open include file<xms.hpp>.You probably don't want to be running CC on its own.
The compiler does not recognize the "make" command
either.
Find below my PATH settings.
"/tools/java/j2sdk1.4.2_08/bin:/usr/bin:/bin:/usr/sbin
:/sbin:/usr/local/bin:/usr/local/sbin:/data/sunstudio1
0/SUNWspro/bin:/opt/mqm/java/bin:/usr/openwin/bin:/dat
a/mqapi/tools/cpp/include:/data/mqapi/tools/samples/co
mmon:/data/mqapi/lib"
where /data/mqapi contains the XMS installation.You need to set your path in your shell. Make sure that /usr/ccs/bin is in your PATH.
Have you really installed Studio 11 in "/data/sunstudio10" - that looks a bit confuding to me!
Paul

Check memory leak using sun studio 10

Hi,
I'm using sun studio 10 to find the memory leak. I pre loaded the librtc.so and attached the process. Then I set the break point at the beginning of scenairo and the end of scenario. Then I trigger the event and program flow hits the break point at the beginning of scenairo, I try to enable the "Memory Check". Then I continue my application. But, I don't see anything show up in the "memory check" tab in the debug window.
Is anyone there who know what is the problem here? Appreciate your help.
Li

Can you help mi. Novice
mail [email protected]

Problems using Sun Studio Express 3 CC on OpenSuse 10.2

Unable to compile a simple program with CC (compiles w/o errors using g++)
-- test.cpp -------------------------------------------------------------------
#include <string>
#include <iostream>
using namespace std;
string xx = "Hello World ...";
int main () {
cout << xx << endl;
return 0;
sunCC -v -o testcc test.cpp
### command line files and options (expanded):
### -v -o testcc test.cpp
### sunCC: Note: NLSPATH
= /opt/sun/sunstudiomars/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/sun/sunstudiom
ars/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
/opt/sun/sunstudiomars/prod/bin/ccfe -y-o -ytest.o -y-fbe -y/opt/sun/sunstudiomars/prod/bin/fbe -y-xarch=generic -
y-xtab -y-verbose -O0 -ptf /tmp/16306%1.
%2 -ptx /opt/sun/sunstudiomars/prod/bin/CC -ptk "-v -xs " -D__SUNPRO_CC=0
x590 -Dunix -Di386 -D__i386 -D__i386__ -D__unix -D__unix__ -D__BUILTIN_VA_ARG_INCR -D__linux -D__linux__ -Dlinux -
D__gnu__linux__ -D__SUNPRO_CC_COMPAT=5 -xdbggen=no%stabs+dwarf2 -y-s -xdbggen=incl -I-xbuiltin -xldscope=global -i
nstlib=/opt/sun/sunstudiomars/prod/lib/libCstd.a -I/opt/sun/sunstudiomars/prod/include/CC/Cstd -I/opt/sun/sunstudi
omars/prod/include/CC -I/opt/sun/sunstudiomars/prod/include/CC/rw7 -I/opt/sun/sunstudiomars/prod/include/cc -y-com
dat test.cpp -s /tmp/ccfe.16306.0.s >&/tmp/ccfe.16306.1.err
rm /tmp/ccfe.16306.0.s
/opt/sun/sunstudiomars/prod/bin/stdlibfilt -stderr </tmp/ccfe.16306.1.err
"/usr/include/string.h", line 272: Error: End of file encountered in macro
arguments for "__nonnull".
"/usr/include/string.h", line 272: Error: ")" expected instead of "(".
"/usr/include/string.h", line 272: Error: Unexpected ")" -- Check for matching
parenthesis.
"/usr/include/string.h", line 272: Error: Operand expected instead of ";".
"/usr/include/string.h", line 426: Error: "strerror_r(int, char*, unsigned)"
is expected to return a value.
"/opt/sun/sunstudiomars/prod/include/CC/new", line 32: Error: operator
new(unsigned) was declared before with a di
fferent language.
"/opt/sun/sunstudiomars/prod/include/CC/new", line 35: Error: operator
delete(void*) was declared before with a di fferent language.
"/opt/sun/sunstudiomars/prod/include/CC/new", line 37: Error: operator new[]
(unsigned) was declared before with a different language.
"/opt/sun/sunstudiomars/prod/include/CC/new", line 40: Error: operator
delete[](void*) was declared before with a different language.
"/opt/sun/sunstudiomars/prod/include/CC/new", line 53: Error: Only one of a
set of overloaded functions can be ext ern "C".
"/opt/sun/sunstudiomars/prod/include/CC/new", line 54: Error: Only one of a
set of overloaded functions can be ext ern "C".
"/opt/sun/sunstudiomars/prod/include/CC/new", line 55: Error: Only one of a
set of overloaded functions can be ext ern "C".
"/opt/sun/sunstudiomars/prod/include/CC/new", line 56: Error: Only one of a
set of overloaded functions can be ext ern "C".
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 106: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 169: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 185: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 198: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 202: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 206: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 217: Error:
Only one of a set of overloaded functi ons can be extern "C".
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 225: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 239: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 249: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 264: Error:
Template declarations cannot have exte rn "C" linkage.
"/opt/sun/sunstudiomars/prod/include/CC/Cstd/rw/iterator", line 275: Error:
Template declarations cannot have exte rn "C" linkage.
Compilation aborted, too many Error messages.
rm /tmp/ccfe.16306.1.err
rm test.o

It is a known bug. Check out this topic: http://forum.java.sun.com/thread.jspa?threadID=5109045
Fix for it should be available in the next installment of Sun Studio Express...
regards,
__Fedor.

Exceptions not caught in shared library when compiled under Sun Studio 9

I realize it's a fairly old version of Sun Studio, however if at all possibly we'd like to avoid updating to the latest.
Sun Studio 9, version reports
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.6 2004/07/15
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.6 2004/07/15
uname -a
SunOS sunblade 5.9 Generic_118558-27 sun4u sparc SUNW,Sun-Blade-100
The problem is within our shared library a function calls another method within a try/catch block. This method then sometimes throws an exception which does have a matching catch block. On all other systems (Windows, AIX, HP-UX, Linux) the code works, the exception is caught and handled. On Solaris with Sun Studio 9 though, the exception is ignored and instead triggers an abort and core dump.
Stack Trace:
ffffffff7daa871c lwpkill (6, 0, ffffffff7fffd9c0, ffffffff7d3064d4, 2, ffffffff7fffd9ec) + 8
ffffffff7da3e4b8 abort (ffffffff7d40dac8, ffffffff7d40cc38, ffffffff7d411e78, 10604c, 2, ffffffff7d40dac8) + 100
ffffffff7d3064d4 __1cH__CimplRdefault_terminate6F_v_ (ffffffff7d40dac8, ffffffff7d40cc38, ffffffff7d411e78, 10604c, 104e40, ffffffff7d3064d0) + 4
ffffffff7d3062b4 __1cH__CimplMex_terminate6F_v_ (ffffffff7d40de40, 0, 0, ffffffff7d40de40, ffffffff7d40c978, 1) + 24
ffffffff7d306f04 exthrow_body (ffffffff7d40de40, 0, 0, 105af4, 52, ffffffff7d40e2e8) + 84
ffffffff7d306e58 __1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_ (ffffffff7d40dec8, ffffffff7f0dea78, ffffffff7ecb6b28, ffffffff7d40de40, 0, ffffffff7d40de40) + 3c
ffffffff7ecb6d90 __1cLIGExceptionFThrow6FnQenumIGErrorCodes_pkcxxp2x_v_ (fffffffffffff3e3, 0, 0, 0, ffffffff7f1187da, a0) + 80
ffffffff7ecb6e78 __1cOThrowException6FnQenumIGErrorCodes_pkcxxp1x_v_ (fffffffffffff3e3, 0, 0, 0, ffffffff7f1187da, a0) + 30
ffffffff7f083304 __1cSIGRasterProcessingNVerifyPalette6FpnMIGRasterPage_nTenumIGContrastModes__v_ (1001f3c10, 0, 0, 0, 0, 0) + b4
ffffffff7f083760 __1cSIGRasterProcessingOInvertContrast6FpnMIGRasterPage_nTenumIGContrastModes_nTenumIGColorChannels_pnPtagAT_RECTANGLE__v_ (1001f3c10, 0, 0, ffffffff7fffe1a8, 0, 0) + 20
ffffffff7f039a2c iIG_IP_contrast_invert (1001f3c10, 100162b10, 0, 0, 0, 0) + 104
ffffffff7f039ba0 iIG_IP_contrast_invert_masked (1001f3c10, 100162b10, 0, 0, 0, 0) + 80
000000010000b4e0 ipcontrast_invert_notify (10014d000, 10014d, 0, 100000, 100162000, 100162) + 48
Try/catch block:
     try
          <Triggering function>
     catch(const IGException& ige)
          <Handling Code>
The code which throws the exception is a static method of IGException which has a basic throw line:
     throw IGException(...);
Source code is compiled with the following flags, none of which I could find any info to suggest affect this:
CC -c -Xt -xCC -misalign -xarch=v9 -O
Linking of the shared object is then done via the following, again nothing obvious that could cause issues. mapfile is an empty file.
ld -o <outputfilename> -G -z textoff -M mapfile -z noversion -64 -h <outputfilename> <object files> -L/opt/SUNWspro/lib/v9 -lCrun -lX11 -lc -lm
I did read somewhere mentioning to make sure to use RTLD_GLOBAL if using dlopen on the .so, but the test app is using ld to link the library.
Does anyone have any ideas why with the Sun Studio 9 compiler these exceptions are not being caught? Based on the fact they are caught on all other compilers, i'm guessing this issue is with the compiler.
Also, as a test it seems that if the shared object is not built as a 64-bit object, then everything works. The issue only seems to occur when it is a 64-bit object. Likely an issue with the 64-bit compiling?
Edited by: 837682 on Feb 17, 2011 9:23 AM

As the other poster pointed out, you need to link the shared library using CC, not ld. I should have noticed that error in the original post.
Try using CC instead of ld in your link command. The CC command causes additional files to be linked into the shared library that are required for proper operation, and particularly for exception handling. I think that is the actual source of your problem.
You should not use -L options that point into the compiler installation area, and when you use CC to link, you don't need to.
I'm surprised that you seem to have a copy of libCrun.so.1 in the compiler installation area -- that should not be the case. The the only versions of libCrun should be static libraries libCrun.a. You almost never want to link with a static version of a system library, and absolutely never when building a shared library. The file /opt/SUNWspro/lib/libCrun.so.1 ought to be a symbolic link pointing to /usr/lib/libCrun.so.1, but if that were the case, the version command would have the same output.
By any chance, did you install your compiler by copying it from another installation? If you do that, you need to use tar, not cp, to ensure that symbolic links are preserved.

Creating EXEs,DLLs using sun studio

Hi friends...
can we use the Sun Studio for creating the EXE's Or DLL's i.e Executables,Dynamic linking library of the Java source file.
which is similar to that of Microsoft Stdio which creates the executables of sourcecodes.
please tell me.....

JoachimSauer wrote:
DrLaszloJamf wrote:
JoachimSauer wrote:
There are tools to generate .exe files, but unless you have a very, very specific need for it, you should probably stay away from them.It's usually at this moment that someone posts a link to one of those nickelwhack tools, and then the OP replies "thanks, just what I needed".I'm painfully aware of that, but (despite much evidence to the contrary) I hope that in those few seconds or minutes between my post and that answer, the OP thinks about it and realizes he doesn't really need an .exe file.Why not distract him by getting him to search for a made-up word like "nickelwhack"?

Error when trying to build using sun studio compiler

Hi ,
When i try to build my appliation-1 and application-2 , I am experiencing below given errors
OS:
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 1
Compiler Version:
cc: Sun Ceres C 5.10 Linux_i386 2008/03/24
usage: cc [ options] files. Use 'cc -flags' for details
Application1:
Error:
CC: Cannot find /comp/sun/sunstudioceres/bin/ccfe
Application2:
Error:
cc: Warning: cannot open inline file /gan/q2/comp/sun/sunstudioceres/lib/amd64/libm.il
cc: Can't exec /comp/sun/sunstudioceres/bin/acomp
Please share your thoughts on how to solve this problem
Regards,

[http://forum.java.sun.com/thread.jspa?threadID=5307985]

Migrating Solaris with out migrating Sun Studio

HI ,
Currently we are using sun studio 8 on solaris 8 to compile our application(C++).
We are planning to migrate Solaris 8 to solaris 10. Will there be any problems, If we use sun studio 8 on sun solaris 10.
Thanks and Regards,
Venkat

Mr.Bond wrote:
HI ,
Currently we are using sun studio 8 on solaris 8 to compile our application(C++).
We are planning to migrate Solaris 8 to solaris 10. Will there be any problems, If we use sun studio 8 on sun solaris 10.Technically speaking, this combination is supported. However, it is rather old, it predates Solaris 10 and having all latest patches installed is a must (see http://developers.sun.com/sunstudio/downloads/patches/ss8_patches.html for list of patches available).
If your final goal is to upgrade both OS and compiler, then switching to Solaris 10 and staying with Sun Studio 8 is a good idea; this way you minimize differences. After dealing with OS differences, you will be able to upgrade to Studio 12 update 1 (most recent release) more smoothly. Latest Sun Studio release is preferable because
- its compiler better conform to the standard,
- they generate better code,
- whole suite works better on Solaris 10 since it was developed and tested on Solaris 10,
- IDE is a huge improvement compared to Sun Studio 8.
However, if you choose to stay with Sun Studio 8 (remember, end of support life is just one year away), I'd recommend purchasing support contract so that if you happen to run into a problem, it is solved with Sun Studio 8 patch, not in the next Sun Studio release (13?), which will be unacceptable for you.

Core dump using iostream with Sun Studio 8

I'm running on Solaris 9 using C++ compiler Sun Studio 8, and encoutered a very strange problem.
My application failed with a core and here is the stack.
[1] t_splay(0x3774b470, 0x387a0ec0, 0x389aec60, 0x39e5ef1f, 0x3774b470, 0x1), at 0xfc347930
[2] t_delete(0x387a0ec0, 0x80, 0x39be9748, 0x20, 0x383ccd20, 0x0), at 0xfc347698
[3] mallocunlocked(0x80, 0x0, 0x21b08, 0xfc3bc000, 0x10, 0x20), at 0xfc346d40
[4] malloc(0x80, 0xfbaa7400, 0x1, 0x759c40, 0x0, 0x0), at 0xfc346b74
[5] operator new(0x80, 0x0, 0xd3a18, 0x759c74, 0x0, 0x8345fc), at 0x760c10
[6] strstreambuf::overflow(0xf41f6e28, 0x29, 0xf41f6e28, 0x39fe0e88, 0x39fe0e88, 0x8345fc), at 0x75bb1c
[7] streambuf::xsputn(0xf41f6e28, 0xfee00bc0, 0x1, 0x0, 0x81010100, 0x1), at 0x75ab94
[8] unsafe_ostream::outstr(0xf41f6e78, 0xfee00bbf, 0x0, 0x0, 0xf41f6e7c, 0xfffffffe), at 0x757bac
=>[9] unsafe_ostream::operator<<(this = 0xf41f6e78, _s = 0xfee00bbf ")"), line 1211 in "iostream.h"
[10] ostream::operator<<(this = 0xf41f6e74, _s = 0xfee00bbf ")"), line 1350 in "iostream.h"
[11] CorInterfaceEntity::ifState(this = 0x1bc3de78, newState = MISMATCH_OF_INSTALLED_AND_EXPECTED, needToSendEvent = false
Can somebody help me giving a direction of investigation ?
Is there perhaps known problem with iostream on Sun Studio 8 running on Solaris 9 ?
Thanks for any tips.
Yaakov Berkovitch
[email protected]

But sorry for my insistence, but do you think that
purify or/and runtime are not able to detect any
corruption of the heap ?They can detect some kinds of corruption, such as some uses of an invalid pointer.
But a wild pointer that changes the value of data that is part of your program cannot be detected by RTC or Purify. Those programs can't know whether that change is intentional.
>
BTW, we are not using any volatile declaration, and weIf non-local data is shared among threads, it should be declared volatile. For example, suppose you have
x = foo;
... // code not changing foo
y = foo;
If foo is not marked volatile, the compiler is allowed to assume its value hasn't changed, and assign to y the same value assigned to x. If foo was changed by another thread, y will not have the current value of foo. The "volatile" declaration says that the variable's value might change without any obvious reason, and the compiler should generate code to load a fresh value each time it is referenced.
are using the rwtools library packaged with the
compiler, and are not using the STD library.OK, you are not running into a std::string synchronization bug.
>
Also about the compiler option -xarch=v8, is probably
not relevant for us because we are running Solaris 9.
So the relevant compiler is probably -xarch=v9. Do you
advise us using this option ?I think you misunderstand. The -xarch values refer to the kind of processor your program will run on.
The -xarch=v8 option generates 32-bit code that will run on all SPARC chips, including the chips found in very old SPARCstations. This option is the default for compilers prior to Sun Studio 9 (which ships this week).
The -xarch=v8plus option generates 32-bit code that runs only on UltraSPARC chips, found in Ultra workstations. These are the only kinds of workstations shipped by Sun since about 1996. Unless you need to support the ancient SPARCstations, we recommend compiling with -xarch=v8plus, to get smaller and faster code.
The -xarch=v9 option generates 64-bit code that runs only on UltraSPARC chips, an only on Solaris 7 or later. Unless your program requires a very large address space, you generally don't want to generate 64-bit code. On SPARC, 64-bit code is larger and slower than 32-bit code. (Type "long" and all pointers are 64 bits instead of 32 bits.)
>
Also I want to return you two new questions:
1) I read in another discussion,
http://forum.sun.com/thread.jsp?forum=5&thread=18124&me
sage=47854#47854
that another memory manager can be more efficient in
multi-threaded environment (libmtmalloc.so), and also
an alternate threads library (/usr/lib/lwp) that
reduced CPU usage. Do you advice us using this
alternate library ?The libmtmalloc library usually has better performance in MT programs than the default version of malloc. It also can result in more memory fragmentation. In that case, the larger working set can sometimes have a large negative effect, more than offsetting the MT efficiency. You have to experiment to see whether it is appropriate for your particlular program. If you are running into heap corruption, the pattern of corruption will probably be different with libmtmalloc than with the default malloc. The differences might provide a clue to what is wrong.
The alternative "T2" threads library was introduced in Solaris 8 as an option.
In Solaris 9 it is the default, so you are already using it.
>
2) We are using the Rogue Wave library shiped with the
compiler. Is it an up-to-date version ? Can we assume
that is a good choice or it will be preferable to move
to the STD library ?I assume you mean Rogue Wave Tools.h++. As explained in the compiler docs, this version of Tools is obsolete, and has not been supported for many years. We continue to provide it for customers who used it before the introduction of the C++ Standard Library in 1998, and who don't want to change their code. We do not recommend it for use in new code.

Using devguide in Sun Studio 11?

Hi!
Newbie question here: Can I use OpenWindows DevGuide as my GUI builder for my application in the Sun Studio 11 compiler?
Any help would be appreciated! Thanks!

My work really is to migrate a GIS application from the Sun Workshop 4.2 Compiler to Sun Studio 11. Since the GUI builder of the application in the old compiler is DevGuide, it also entails changing it to X-Designer.
I already used the "gil2xd" utility but the GUI in DevGuide is better than that of X-Designer. Another problem is porting from Xview(used in DevGuide) to MOTIF Library(used in X-Designer). There is no one-to-one correspondence between the functions and attributes of the two libraries.
This is really the remaining and hardest part of the migration process. I was thinking if Xview is compatible with X-Designer so that I could just retain the codes but still get the same results.
Thank you for all the help, guys!
Rix

Using GDB to debug a code compiled with Sun cc

When using gdb to debug C code compiled with Sun's cc, the step-into doesn't work, i can only "step into" a function if i put a breakpoint on it. Also, sometimes if i set a breakpoint on a function name, like "break foo", gdb indeed breaks when foo is reached, but without showing the source code (this i could not reproduce with a small demo program).
I am using Sun Studio 12 on a SunOS 5.10 sun4u sparc machine.
My demo program is:
#include <stdio.h>
#include <strings.h>
void func1(str)
char str;
printf("This is the first line\n");
printf("STR: %s\n",str);
int main()
char str[10];
strcpy(str,"lalalal");
printf("Calling func1\n");
func1(str);
printf("Returned from func1\n");
The compilation command i run is:
cc -c -g step_into.c -o step_into.o
cc -g -o step_into step_into.o
When running the program with gdb, the "step" command does not step into func1, but runs it like "next".
I know there's the dbx debugger, but if there's a way to fix this with gdb - it is much preferable for us. Switching to dbx is not really feasible for us.
Regards,
Yael

Hello Yael,
I tried your example on my laptop (OpenSolaris x86/x64) with Sun Studio 12 update 1
and GDB 6.3.50 - it works properly:
$ gdb dist/Debug/SunStudio-Solaris-x86/forum_c_20091230
GNU gdb 6.3.50_2004-11-23-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.11"...
(gdb) break main
Breakpoint 1 at 0x8050a87: file src/args.c, line 15.
(gdb) run
Starting program: /export/home/nikm/SunStudioProjects/Forum_C_20091230/dist/Debug/SunStudio-Solaris-x86/forum_c_20091230
Breakpoint 1, main () at src/args.c:15
15         printf("Calling func1\n");
Current language: auto; currently minimal
(gdb) next
Calling func1
16         func1(str);
(gdb) step
This is the first line
func1 (str=0x80477ba "lalalal") at src/args.c:7
7         printf("STR: %s\n",str);
(gdb) Could you please download and try Sun Studio 12 update 1?
It is available for free. Here is the web page:
http://developers.sun.com/sunstudio/
BTW, which GDB version do you use?
I'll try it on a sparc system and let you know.
Thanks.
Nik
P.S.: there is a typo in the source code:
void func1(str)
*char *str;I think it should be:
void func1(char *str)Probably a copy-paste problem.
Please use "CODE" mode when you copy-paste source lines (selected text, press 'CODE' button).

Compiling iperf on Solaris 10 8/07 w/ Sun Studio 12 -- Errors

/var/tmp/iperf-2.0.2 (nocc-testjump) #> /usr/local/bin/make
/usr/local/bin/make all-recursive
make[1]: Entering directory `/var/tmp/iperf-2.0.2'
Making all in compat
make[2]: Entering directory `/var/tmp/iperf-2.0.2/compat'
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include    -O2 -MT delay.o -MD -MP -MF ".deps/delay.Tpo" -c -o delay.o delay.cpp; \
        then mv -f ".deps/delay.Tpo" ".deps/delay.Po"; else rm -f ".deps/delay.Tpo"; exit 1; fi
In file included from /usr/include/sys/wait.h:24,
                 from /usr/include/stdlib.h:22,
                 from ../include/headers.h:78,
                 from ../include/Timestamp.hpp:63,
                 from delay.cpp:53:
/usr/include/sys/siginfo.h:259: 'ctid_t' is used as a type, but is not defined
   as a type.
/usr/include/sys/siginfo.h:260: 'zoneid_t' is used as a type, but is not
   defined as a type.
/usr/include/sys/siginfo.h:390: 'ctid_t' is used as a type, but is not defined
   as a type.
/usr/include/sys/siginfo.h:391: 'zoneid_t' is used as a type, but is not
   defined as a type.
make[2]: *** [delay.o] Error 1
make[2]: Leaving directory `/var/tmp/iperf-2.0.2/compat'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/iperf-2.0.2'
make: *** [all] Error 2
/var/tmp/iperf-2.0.2 (nocc-testjump) #> Any ideas why I'm getting this problem?

In general, if you are having a problem compiling Open Source code with Sun Studio, you need to try the community support portal for that code.
Start with the Iperf home page
[http://starplane.org/tooldoc/iperf/]
Often, Open Source code has been tried only with gcc, and won't build with other compilers without some effort.
If nobody else has tried using Sun Studio, you might need to do some debugging of configuration scripts and even source code.
The Iperf home page provides an address where you can report such problems.
In addition, older versions of autoconf and libtool don't work with Sun Studio, and can generate invalid makefiles. Be sure you have the current versions of both, if they are used by Iperf.

Problem in compilation using Sun Studio 11

Similar Messages

Maybe you are looking for