Compiler installation

Hi
I'm quite new to solaris and I need to generate some executables on my Solaris 9 box using make files. In the make file I've the compiler set as follow "CC = cc"
I tried to use /usr/ucb/cc but doesn't work
then I've installed gcc 3.3.2 and use it (changing my mk file form "CC = cc" to "CC = gcc" but I receive the following error
gcc: cannot specify -o with -c or -S and multiple compilations
Anyone can help me?
Best Regards
Paolo

Hi Paolo,
I suggest you download and install Sun Studio 12, which can be found at http://developers.sun.com/sunstudio/downloads/index.jsp. After that run bash and export CC=cc. Sun Studio 12 installer creates /usr/bin/cc symlink to it's binary, so from here, everything should work fine.
Peter

Similar Messages

LD_LIBRARY_PATH setting for a typical compiler installation

What is the setting of the LD_LIBRARY_PATH environment variables (all three forms, i.e., including the ones with the _32 and _64 suffix) we can expect on a typical Sun C++ installation on SPARC? Can we expect only LD_LIBRARY_PATH to be set or do the
suffix forms get defined as well (or instead)? We need to know which variable(s) to
modify in our infrastructure and since the suffix forms override the generic one it makes
a difference.

Yup, LD_LIBRARY_PATH is also discouraged for installations in
alternate directories. All the Sun Studio tools themselves will
run just fine without needed any of these variables. But we do
ship with shared libraries for our users to use in their apps.
By default the compilers will add RPATH settings into the exectuables
to find the shared libraries in the compiler install directory
(wherever that happens to be during compile time). But if the
end user doesn't have the same compiler installed in the same place,
then the creator of the executable has to decide how to deal with it.
One choice they have is to tell the end user to install the runtime
libs in an arbitrary spot, and then use LD_LIBRARY_PATH.
We try to discourage that, but we're not in a position to enforce it.
It's better to ship the runtime libs in a fixed position relative to the executable
that you're shipping, and use $ORIGIN in the RPATH setting.
--chris

Issue with gcc compiler installation

Hi ,
To install the C Compiler(gcc compiler) on Solaris 9.0 ,I unzipped the following tar files SUNW0gccfss.tar.bz2 and gccfss_src.tar.bz2 but after that when I type gcc ,I get that "SUNW0gccfss is not installed".
Even I used cc command to compile the C Program but I get this error message "language optional software package not installed"
Please advise.
Thanks
Bala

For Sun Studio tools you can download from http://developers.sun.com/sunstudio/downloads/index.jsp . Note the "cc" is /usr/ucb/cc normal shell script which will pickup the sun studio compiler if its installed. If its not present then it throws the error messaget "language optional software package not installed"
If you are looking for compiling with GCC. Grab hold of the Solaris Companion CD from http://www.sun.com/software/solaris/freeware/ and install the all the gcc releated . The CD has "installer" script to install all the development packages.

Problem - C++ Compiler Installation on Solaris

Hello:
I am facing the following Software installation Problem.
Any recomendations/tips ??
thanks,
Salman.
PIONEER DATA SYSTEMS, INC.
E-mail: [email protected]
Description:
Space Available on the machine.
Output of df -k command
$ df -k
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0d0s0 1186398 1019926 107153 91% /
/dev/dsk/c0d0p0:boot 10484 1623 8861 16% /boot
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
mnttab 0 0 0 0% /etc/mnttab
swap 441524 0 441524 0% /var/run
swap 441884 360 441524 1% /tmp
/dev/dsk/c0d0s7 5482998 1215814 4212355 23% /export/home
There is about 4GB space in /export/home
We want to install Forte C++ on this machine. The default directory at which the software is installed is /opt. It also gives option to change the install
Directory. We created a directory Forte under /export/home and provided
/export/home/forte as install directory.
We selected the following software for installation.
License Software (FLEXIm7.0)
License patches for Forte Developer 6
Forte C++ Enterprise Edition 6
It gives WARNING INSUFFICIENT DISK PARTITION SPACE TO INSTALL THE ITEMS SELECTED.
WARNING: /export/home/forte has insufficient space to install the items selected. 206.7 MB additional space would be needed to install the selected items.
Total Space Required:
Product: License Software (FLEXIm7.0)
Location:/export/home/forte
Size 5.9MB
Product: License patches for Forte Developer 6
Location:/export/home/forte
Size 479KB
Product: Forte C++ Enterp Ed 6/Intel
Location:/export/home/forte
Size 272.1MB
Problem:
If you add up the space required, it is
5.9 + .479 + 271.1 = 277.5 MB
It's complaining that it needs 206.7 MB additional space?
There is 4 Gig space in that directory...
-------------------------------------------------------------------------

It seems to me that unsufficient space in the root dir. Just advice: make root bigger and try to found out how to make /opt with necessary size. You will have problem if you install in non default path and will fix it.
Regards,
Kirill Petrov

Question about Compiler Installation

Hi everyone. Haven't been in this forum for a while.
Anyho, I was wondering. I'm about to run a compiler program called "JCreator LE", and I came upon this message:
"In order for you to make use of the java documentation, you need to have a recent version of JDK JavaDocs installed on your system."
Select the JavaDocs home directory: eg. C:\jdk1.4\docs
I tried looking into my jdk1.4.1_04 folder, but I couldn't locate the source.
So what is JavaDocs, and what is the most appropriate site(s) to download this source?
thanks, Greg

The JavaDocs are basically the Java API Documentation. You can download any version at http://java.sun.com/docs/ or you can view the complete API docs online at http://java.sun.com/j2se/1.4.2/docs/api/index.html

How to unpack an installer previously compiled with Inno Setup?

Hi,
I want to know how can I unpack a previously compiled installer (exe file) made with Inno Setup to extract and recover some DLL files into the installer. I found a tool called InnoExtractor
that supposedly
does this, but I don't know how is work. Any help is appreciate. This tool can by downloaded from here:
http://www.softpedia.com/get/Compression-tools/InnoExtractor.shtml
Regards and I'll wait your support. Thanks in advance.

Hello GonKong,
I am afraid that this is not the proper forum for this issue, since it is related to the tool which belongs to third-party.
I would recommend you consider connecting with the publisher of Inno Setup or InnoExtractor to get supports.
Regards.
Carl
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

SUNWspro iostream error while compiling with SunStudio 10

We are getting the following error when we try to compile the C++ code using SunStudio 10 on Sun Solaris Sparc server.
We made couple of changes in the source code 1) whereever we have stream.h we replaced it with iostream.h and 2) include fstream.h whereever required.
Can anyone tell us where did it go wrong.
+ /opt/SUNWspro/bin/CC -g -O -DHAWK -mt -lclntsh -lsocket -lnsl -I/export/home/StandardComponents/SC/include -I../../mylib -I../../include -I/opt/SUNWspro/prod/include/CC/Cstd -I. -I- -D_TRACE_ -c collectDborMtoInfo.c
"/opt/SUNWspro/prod/include/CC/Cstd/iostream.h", line 20: Error: Use ";" to terminate declarations.
"/opt/SUNWspro/prod/include/CC/Cstd/iostream.h", line 20: Error: A declaration was expected instead of "'\n'".
"/opt/SUNWspro/prod/include/CC/Cstd/iostream.h", line 20: Error: Use ";" to terminate declarations.
"/opt/SUNWspro/prod/include/CC/Cstd/iostream.h", line 20: Error: A declaration was expected instead of "'\n'".
4 Error(s) detected.

Remove the -I directive that points into the compiler installation. You should not have have -I or -L options that point into the compiler installation area, into /usr/include, or into /usr/lib. The CC compiler driver knows where to find system headers and libraries, and in what order to search the directories. If you force a different search order, you can break something.
If removing -I/opt/SUNWspro/prod/include/CC/Cstd does not fix the problem, compiling with -P or -E will show you the preprocessor output, and looking at the lines with the errors will usually show the source of the problem quickly.
BTW, you should be aware that the ".h" form of the C++ headers, like <iostream.h> and <fstream.h>, is not standard. Using them is not portable, because not all C++ implementations provide them, and those that do often have different content.

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.

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.

Problems compiling stlport4.6.2 with Forte CC 5.4

Hi,
I am compiling stlport 4.6.2 with CC 5.4 and i have this error:
/opt/FORTE/SUNWspro/bin/CC -mt -library=no%Cstd -features=rtti -xildoff -I. -I/users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../stlport -O2 -qoption ccfe -expand=1000 -PIC -ptr/users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../lib/obj/SUN/ReleaseD dll_main.cpp -c -o /users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../lib/obj/SUN/ReleaseD/dll_main.o
"/users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../stlport/stl/debug/_debug.c", line 246: Error: va_list is not a member of std.
"dll_main.cpp", line 151: Where: While instantiating "static _STL::__stl_debug_engine<bool>::_Message(const char*, ...)".
"dll_main.cpp", line 151: Where: Instantiated from non-template code.
"/users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../stlport/stl/debug/_debug.c", line 246: Error: __args is not defined.
"dll_main.cpp", line 151: Where: While instantiating "static _STL::__stl_debug_engine<bool>::_Message(const char*, ...)".
"dll_main.cpp", line 151: Where: Instantiated from non-template code.
"/users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../stlport/stl/debug/_debug.c", line 246: Error: Badly formed expression.
"dll_main.cpp", line 151: Where: While instantiating "static _STL::__stl_debug_engine<bool>::_Message(const char*, ...)".
"dll_main.cpp", line 151: Where: Instantiated from non-template code.
"/users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../stlport/stl/debug/_debug.c", line 247: Error: __args is not defined.
"dll_main.cpp", line 151: Where: While instantiating "static _STL::__stl_debug_engine<bool>::_Message(const char*, ...)".
"dll_main.cpp", line 151: Where: Instantiated from non-template code.
"/users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../stlport/stl/debug/_debug.c", line 266: Error: __args is not defined.
"dll_main.cpp", line 151: Where: While instantiating "static _STL::__stl_debug_engine<bool>::_Message(const char*, ...)".
"dll_main.cpp", line 151: Where: Instantiated from non-template code.
5 Error(s) detected.
make: *** [users/comun/personales/manuel/STLPort/STLport-4.6.2/src/../lib/obj/SUN/ReleaseD/dll_main.o] Error 5
I�d supressed the warning messages for cleaning the error.
Thanks in avanced.

C++ 5.4 (with recent patches) comes with STLport version 4.5.3. You use it by adding the option -library=stlport4 to every CC command line. Is there some reason why you can' t use that version of STLport?
STLport is very difficult to configure. When we finally got STLport 4.5.x working with C++ 5.4, we gave the changes back to Boris. I don't know whether later STLport updates preserved the fixes we made.
If you must build your own version of STLport 4.6.2, compare your configuration with what comes with the compiler. Some of the error messages look like configuration errors.
Historically, the STLport build process was not correct for using recent Sun compilers on recent versions of Solaris. Be sure that STLport is NOT using its own versions of the C standard headers. Check the compiler options in the Makefiles, and remove any -I directives that point into /usr/include or into the compiler installation area. If the compiler options include w2, change it to w or remove it entirely. The w2 option will generate a lot of warnings that are not relevant to building the C+ standard library.

Error on compiling Vim 6.4

I have dowloaded the Vim 6.4 tar file, and untar the same successfully.
When i try doing a make i get the following error msg.
/opt/gnu/lib/gcc-lib/sparc-sun-solaris2/2.5.8/include/sys/signal.h:95: conflicting types for `sigset_t'
/usr/include/sys/select.h:46: previous declaration of `sigset_t'
gmake[1]: *** [objects/buffer.o] Error 1
gmake[1]: Leaving directory `/users/arthini/vim/vim64/src'
gmake: *** [first] Error 2
Can you help me out in installing vim 6.4 on my system.

Never use -I options that point into /usr/include or into the compiler installation area.
The compiler knows where to look for system headers, and the order in which to search the directories. When you force the compiler to search the directories in the wrong order, you can prevent the right files from being found.
If you added -I/usr/include to solve some problem, look for a different solution. (If you explain what that problem was, I can suggest another solution.)

Can't find library when compiled with debugging

Hi all,
Compiling this code segment cannot find a library when using -g
bash-3.2$ cat tester.cc
#include <iostream>
#include <string>
using namespace std ;
static void
myRoutine()
string str= "this is in routine" ;
string str3 ;
str3 = str.substr(11,7) ;
if(str.substr(0,4) == "this") cout << "Have a hit" << endl ;
cout << "this is str3 - " << str3 << endl ;
int main(int argc, char **argv)
string str = "this is a test" ;
string str1, str2 ;
str1 = str.substr(0,4) ;
str2 = str.substr(10,4) ;
cout << "this is str1 - " << str1 << endl ;
cout << "this is str2 - " << str2 << endl ;
myRoutine() ;
return 0 ;
bash-3.2$ CC -g -o tester tester.cc
bash-3.2$ ldd tester
     libCstd.so.1 =>     /usr/lib/libCstd.so.1
     libCstd.so.1 (SUNW_1.4.2) =>     (version not found)
     libCrun.so.1 =>     /usr/lib/libCrun.so.1
     libm.so.2 =>     /usr/lib/libm.so.2
     libc.so.1 =>     /usr/lib/libc.so.1
If I comment out:
if(str.substr(0,4) == "this") cout << "Have a hit" << endl ;
bash-3.2$ cat tester.cc
#include <iostream>
#include <string>
using namespace std ;
static void
myRoutine()
string str= "this is in routine" ;
string str3 ;
str3 = str.substr(11,7) ;
// if(str.substr(0,4) == "this") cout << "Have a hit" << endl ;
cout << "this is str3 - " << str3 << endl ;
int main(int argc, char **argv)
string str = "this is a test" ;
string str1, str2 ;
str1 = str.substr(0,4) ;
str2 = str.substr(10,4) ;
cout << "this is str1 - " << str1 << endl ;
cout << "this is str2 - " << str2 << endl ;
myRoutine() ;
return 0 ;
bash-3.2$ CC -g -o tester tester.cc
bash-3.2$ ldd tester
     libCstd.so.1 =>     /usr/lib/libCstd.so.1
     libCrun.so.1 =>     /usr/lib/libCrun.so.1
     libm.so.2 =>     /usr/lib/libm.so.2
     libc.so.1 =>     /usr/lib/libc.so.1
Or if I remove -g:
bash-3.2$ cat tester.cc
#include <iostream>
#include <string>
using namespace std ;
static void
myRoutine()
string str= "this is in routine" ;
string str3 ;
str3 = str.substr(11,7) ;
if(str.substr(0,4) == "this") cout << "Have a hit" << endl ;
cout << "this is str3 - " << str3 << endl ;
int main(int argc, char **argv)
string str = "this is a test" ;
string str1, str2 ;
str1 = str.substr(0,4) ;
str2 = str.substr(10,4) ;
cout << "this is str1 - " << str1 << endl ;
cout << "this is str2 - " << str2 << endl ;
myRoutine() ;
return 0 ;
bash-3.2$ CC -o tester tester.cc
bash-3.2$ ldd tester
     libCstd.so.1 =>     /usr/lib/libCstd.so.1
     libCrun.so.1 =>     /usr/lib/libCrun.so.1
     libm.so.2 =>     /usr/lib/libm.so.2
     libc.so.1 =>     /usr/lib/libc.so.1
then I can run successfully
Any thoughts or hints?
bash-3.2$ CC -V
CC: Sun Ceres C++ 5.10 SunOS_i386 2008/07/10
Usage: CC [ options ] files. Use 'CC -flags' for details
bash-3.2$ uname -a
SunOS alpha 5.11 snv_86 i86pc i386 i86pc
Thanks,
Jim

Ack! Please ignore my earlier posting. I did not play close enough attention to details in your post. I apologize for the confusion. Let me start over:
The Studio Express release you have contains a newer version of the C++ runtime library libCstd.so.1 than is available yet in Solaris patches. We bump the internal version number when we add new interfaces. The internal version number of the Studio Express library is SUNW_1.3.2. The version of the latest release Solaris patch is SUNW_1.3.1.
Some new string class operator functions are in version SUNW_1.3.2. I think these are also defined as inline functions in the compiler headers. When you compile with -g, inlining is disabled, and you create a dependency on library version SUNW_1.3.2. (Compiling with -g0 allows function inlining, and might resolve your problem, but read on.)
We have not released a libCstd.so.1 with internal version SUNW_1.4.2, so I don't understand how that version number could appear in an error message. Did you really see that version, or is it a transcription error? For now, let's assume it is a transcription error.
When you compile and link with CC, the program gets a runpath pointing into the compiler installation area. At program run time, the loader looks for libraries in directories listed in the runpath, with /lib and /usr/lib as last resort. The "ldd" command reports what the runtime loader will do regarding dependent libraries.
If the compiler is installed in /opt, a 32-bit program gets a runpath that includes /opt/SUNWspro/lib. In that directory in Sun Studio Express is a symbolic link that points to ../prod/usr/lib/libCstd.so.1, the library with version SUNW_1.3.2.
If you try this:
% /opt/SUNWspro/bin/CC hello.cc
% ldd a.out
you should see, among other things,
libCrun.so.1 => /opt/SUNWspro/lib/libCstd.so.1
(Depending on the OS version, you might see
libCrun.so.1 => /opt/SUNWspro/prod/usr/lib/libCstd.so.1 instead.)
But if ldd can't resolve the library, you probably have a corrupted Sun Studio Express installation. In that case, uninstall it, and reinstall from a fresh download.
If you run the program on a different computer where Sun Studio Express is not installed, the loader won't be able to find the right library version, and you will get "not found" results. I addressed this issue in another thread:
http://forums.sun.com/thread.jspa?threadID=5340163

Command Line Compilation of a Project with different packages

Hi,
I am trying to compile a project through command line, which has different packages with many classes in it. Now If I try to compile package by package It's complaining about other referenced classes of different packages. So I created .bat file, which includes all the packages, but it's complaining input line is too long.
D:\jdk1.3.1\bin>app.bat
My bat file is
javac -d d:\Application\build d:\Application\source\com\ibc\rules\login\*.java d:\Application\source\com\ibc\rules\lookup\*.java .................d:\Application\source\com\ibc\wid\events\*.java d:\Application\source\com\ibc\wid\frames\cust\*.java ...
and so on............
Is there any solution for this problem?
Thanks in advance....

I think the prefered and more elegant way to compile project including packages should be writing makefiles including their compilation, installation, deploying - rules ..
Make is really powerful, the maybe only weak-point is that there are some distribution of them, gnu-make, microsoft nmake .. which are slightly different, that made porting among platforms difficult.
The jakarta-ant was a new approach to this which uses xml parser to proof the dependencies, etc ..
Because I'm not familiar yet with xml & ant and as a in-blooded unix user, "make" is still my prefered way to do roject.
The easiest way to get unix environment required for using make in Windows platforms is to download the "unxutils". It includes make, bzip2, diff, ... and other unix-tools. Refer to this (found from search by google) :
http://www.weihenstephan.de/~syring/win32/
http://www.weihenstephan.de/~syring/win32/UnxUtils.zip
http://sourceforge.net/projects/unxutils/
For more documentation on how to write makefile, use make -tool, see
http://www.gnu.org/manual/
http://www.gnu.org/manual/make-3.79.1/html_mono/make.html

Sun Studio and ANSI C compilation

Hello, I have a program developed by a third party and it says i need to have a ANSI C99 compatible complier. Does Sun Studio have ANSI C compilation capabilities? If yes, what is the minimum version on Sun Studio that I should have, inorder to have this compiled. I am new to this OS and C programming. Please help.

Assuming you are using Sun Studio 12, full C99 compliance is the default when running on Solaris 10.
The basic flags you care about most often are about the same as any Unix or Linux compiler:
-c compile only
-g compile for debug
-O moderate optimization
-I<dir> add <dir> to the list of directories searched for header files
-L<dir> add <dir> to the list of directories searched for shared (dynamic) libraries
The C++ Users Guide appendix on compiler options describes all options in detail. You can find it via the "docs" directory in the compiler installation, or you can go here directly:
http://docs.sun.com/app/docs/doc/819-5265/bjapp?a=view

What's the best way to mix AIR 14 and the Flex 3.5 SDK and use new AIR features?

I am returning to development of a popular desktop AIR app, after about 4 years of no code changes. Both AIR and Flex have actively moved forward during my coding absence, and it is time to play catch up.
When last built, the app was using Flex 3.5 and AIR 2.6.
End Goal - I want my app to look good on high density displays
I'd like to keep Flex version at 3.5, but use the newer version of AIR, to render more clearly on high density displays (Retina on OSX and hiDPI on Win8).
The pixel doubling performed by the "compatibility" modes of OSX.Retina or Win8.hiDPI make my app look pretty gross, and the customer base is starting to complain.
While I may eventually switch over to the Apache Flex SDK to bring the application design into the current state, my customer base just doesn't care right now. They like the current app, but want it to work, out-of-the-box, on high density displays.
So I need to limit my scope to changing only the AIR SDK, not the Flex SDK at this time.
Step 1 - Overlaying AIR14 SDK on Flex 3.5
I followed the official generic overlay instructions here, and that worked well enough. I named my hybrid SDK folder "3.5.0.AIR14". I have been able to recompile, run, and verify my app using the hybrid SDK. (my app is compiled and packaged from an ant script, using the Antennae framework. I had already switch SDKs a number of times over the initial course of development, so pointing my project to a new SDK was pretty simple enough.
Step 2 - Updating the app.xml descriptor
This part was also easy. I used the templates\air\descriptor-template.xml as a starting point, customizing the name, app id, and folders. Now my app descriptor is correctly based on the <application xmlns="http://ns.adobe.com/air/application/14.0"> namespace.
Step 3 - Enabling Retina/hiDPI support - Help??
I added <requestedDisplayResolution>high</requestedDisplayResolution> to the <initialWindow> tag of the app descriptor, but that made no difference. The app compiles, installs, and runs, but pixel doubling is still occurring and the app looks gross.
I also tried setting the SWF version to 25, according to the official overlay guide. This proved to be more difficult. The official overlay guide suggests setting the -swf-version=25 compiler option, but that option is not supported by the Flex 3.5 compiler. So all I had to try was using the legacy -target-player=25 compiler option. That setting was accepted by the compiler, and it produced a SWF with byte offset 0x3 == 0x19 (25 dec), so that appears to be right.
But -target-player=25 didn't have any effect either.
Is setting the SWF version even required? Isn't the whole point of using the AIR 14 namespace in the app descriptor the way of telling the compiler "I want to use all features of the AIR 14 release". Why do I need to tell the compiler multiple times to use all the features of the SDK I'm compiling with? It just seems weird to me.
Have I missed a secret setting somewhere?
How can I tell the AIR runtime to simply run as pixel-dense as possible? When the workarounds listed below are performed, my app looks fantastic on high-density displays. But its the pixel scaling that is making everything look bad, and I desperately want to get this fixed.
Workarounds?
On Windows 8+, we are asking our users to enable the "Disable display scaling on high DPI settings" checkbox on the AIR application shortcut. This works, but is a confusing setting for average users to discover. Most just give up in frustration.
On OSX, we can't even disable Retina mode on a per-application basis, its all or nothing, so that's even worse. SwitchResX will automatically switch resolutions based on the selected app, but that's a pretty clunky (and non-free) workaround too.
Any other workaround ideas are appreciated too.
Cheers,
Doug

It took me a while to figure out (without much help from Adobe, grrr!), since some internet writeups were terse and implied somehow that AIR's Retina support (setting your app descriptor's <initialWindow/requestedDisplayResolution> to high) would also work on Windows. They don't.
On OSX, the steps to disable pixel-doubling are:
update your app descriptor to AIR 14
set initialWindow/requestedDisplayResolution = high
compile with SWF version 25 or greater
vector assets, including text, will scale automatically
you'll need to replace your bitmap assets with Retina-quality bitmaps as appropriate
when running on a Retina display, you will see stage.contentsScaleFactor=2. It will be 1 for non-Retina displays.
On Windows, the pixel-doubling kicks in when you have a HiDPI scaling set to about 150% or greater (hiDPI scaling was introduced in Win7). There is no way to detect from within an AIR app when Windows is doing its HiDPI scaling. stage.contentsScaleFactor is always 1, under all configurations.
The only thing you can do for AIR apps on Windows is explicitly disable display scaling (like you have done) and update your app to manually scale all UI elements at runtime (that's really gross and hard, and it what I working on right now).
For my app, I updated our Windows installer to set the registry to disable hiDPI scaling, for all users, just for our app. Here's how you do that:
Key = HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
Name = <fullPathToYourExe>
Type = REG_SZ
Value = "~ HIDPIAWARE" (without the quotes, tilde space HIDPIAWARE)
That should be set in the full 64-bit registry, not the Wow32Node registry, even if your app is a 32-bit app (which all AIR apps are). If your installer is a 32-bit app (mine was), you may need to jump through some hoops to have it affect the 64-bit registry hive from a 32-bit process.
If you only want to change the setting for the current user (not all users), the KEY root is HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE.
If you don't have an explicit installer for your AIR app (ie. if you are deploying from the web via a badge installer), then you're even more messed up, and you will need to tell your users to disable the scaling manually.
I know, it's a total pain. I hope this helps.
Cheers,
Doug
PS: Adobe devs, if you are listening ...

Compiler installation

Similar Messages

Maybe you are looking for