Dmake -j

Hello,
I'v got a little problem with dmake.
I'd like to use it with 4 jobs. So I used : "dmake -j 4 all"
During the compilation I got the warning :
dmake: defaulting to parallel mode.
See the man page dmake(1) for more information on setting up the .dmakerc file.
suncompile2 --> 1 jobI don't understand why there is only 1 job.
The .dmakerc file is not defined on my system. I checked the locations specified in the dmake man page :
     1. The path name you specify on the command line using the
         -c option
     2. The path name you specify using the DMAKE_RCFILE
         makefile macro
     3. The path name you specify using the DMAKE_RCFILE
         environment variable
     4. $(HOME)/.dmakercBut in theory the -j option should enable me to run dmake with more than one job :
     If a runtime configuration file is not found, dmake switches
     to parallel mode and distributes two jobs (the default) to
     the dmake host. You can change this using the -j option, or
     DMAKE_MAX_JOBS.Can someone explain it to me ?
PS : Sorry for my english.

suncompile2 --> 1 jobonly says that currently dmake is waiting for 1 job to complete. If you
grep " job$" your build log, you may encounter other numbers. If there still are only "1"s, we would need to see your makefiles as ability of dmake to run several jobs in parallel depends on how makefile is written.

Similar Messages

Dmake is very very slow in our builds (HELP please!!!)

We use dmake (with makedepend) in our builds and our build time for the entire system is extremely slow (it takes 17+ hours to do a clean build).
Could anybody suggest a solution or remedy to help us reduce the long build times.
We use solaris 2.6 with Forte 6.0 C++. Our sources are mounted on a shared filesystem/disk and they are not local to where the build happens.
Any help in this regard is highly appreciated.
Thanks.

Your build server has 2 CPUs, so it makes sense to use
dmake in parallel mode instead of make. I'm responsible
enginerr for both, make and dmake, and I can say that
they are compatible. People, who don't care about the
build time, can use any of them. People, who cares about
build time, should use 'dmake -m parallel -j 8' if they have
only 2 CPUs.
Of course each build can have some specific, but in
general it makes sense to allow 4xN parallel jobs (where
N is the number of CPUs). Also there is an ability to run
this build on several build servers (see 'man dmake' for
details about the build in distributed mode), or to run this
build in "grid" mode, but first of all you have to make sure
it works in parallel mode.
So I suggest you to try the following experiment:
1. Replace "make" with "$(MAKE)" in makefiles
2. Run build with "time dmake -m parallel -j 8 ..."
If you see that "user"+"sys" time is twice bigger than the
"real" on a 2 CPU system, this is the best result this
build can show. If "user"+"sys" is less than the "real"
time, there is a room for imrovement.
Please, let me know the results.
Thanks,
Nik

Make and dmake included with Solaris 10/Studio 11

Subject: make and dmake included with Solaris 10/Studio 11
I've been working on a project where I'm converting makefiles that were originally developed for GNU make to utilize dmake.
The one issue I've been having is that one dynamic macro "$<" (insert dependency) doesn't seem to work as documented in the make man page either with dmake and make (in /usr/ccs/bin, or /usr/xpg4/bin). Here's a small snippet of what I'm trying to figure out:
#### Targets
oraSQL.c: oraSQL.pc
$(ORACLE_HOME)/bin/proc iname=$< dbms=v8 HOLD_CURSOR=NO RELEASE_CURSOR=YES ireclen=132 oreclen=132 select_error=no lines=yes sqlcheck=semantics xref=yes CODE=CPP ORACA=YES MODE=ORACLE MAXOPENCURSORS=50 userid=$(CONNSTR) When make executes this, it should replace the "$<" with "oraSQL.pc". This does work with GNU make. Now, I know that Solaris make and GNU make are definitely not the same; the manpage for Solaris make at the section titled "Dynamic Macros", clearly states that the same behavior should exist. Unfortunately with Solaris make, the macro is simply replaced with nothing.
Am I being a blockhead, or is there more too this that someone here might know about?
Thanks in advance;

First of all, this is a well known problem. It is not a bug, but a
difference in behavior between Sun "make" and GNU "make".
The behavior of Sun "make" is documented in man page,
and we cannot change the default behavior because this will
break the existing builds.
Here is how it is documented in make.1 man page:
$< The name of a dependency file, derived as if
selected for use with an implicit rule.
Second, this problem has been reported several times (see CR
6593262 for example) , and we addressed it - we provided
environment variable to specify the compatibility mode.
SUN_MAKE_COMPAT_MODE=GNU
- compatibility with GNU "make"
Compatibility with GNU "make" is partially implemented, and
will be improved in next releases.
Here is an example how to set SUN_MAKE_COMPAT_MODE
to avoid the problem, mentioned in CR 6593262:
1. This is what happens if SUN_MAKE_COMPAT_MODE is not set.
% unsetenv SUN_MAKE_COMPAT_MODE
% cat Makefile
## -- Makefile --
ECHO=/usr/bin/echo
all: this
that:
$(ECHO) "soccer"
this: that
$(ECHO) $<
% dmake -m parallel this
/usr/bin/echo "soccer"
soccer
/usr/bin/echo
2. Here is what happens if SUN_MAKE_COMPAT_MODE=GNU
% setenv SUN_MAKE_COMPAT_MODE GNU
% env | grep SUN_MAKE_COMPAT_MODE
SUN_MAKE_COMPAT_MODE=GNU
% dmake -m parallel this
/usr/bin/echo "soccer"
soccer
/usr/bin/echo that
that
So, in this case the output is identical to GNU make, correct?
Please, try to set the environment variable:
SUN_MAKE_COMPAT_MODE=GNU
and restart your build.
Thanks,
Nik

Hanging dmake

I've just moved a user account home directory and when I attempt to run dmake in distributed mode, it spins hogging a CPU apparently doing nothing.
The output from truss is:
stat64("/export/home", 0x08045B60) = 0
llseek(8, 0, SEEK_CUR) = 0
llseek(8, 0, SEEK_SET) = 0
ioctl(8, (('m'<<8)|7), 0x08045714) = 0
ioctl(8, (('m'<<8)|7), 0x08045714) = 0
ioctl(8, (('m'<<8)|7), 0x08045714) = 0
repeated over and over.
Any clues?
Ian.

It looks like the problem as caused by the user's home directory being on a lofs type filesystem in a zone. Removing the filesystem from the zone and mounting it through vfstab from the global zone fixed the problem, whatever it was...
Ian

Dmake from SunStudio 11 - ssh instead of rsh?

Howdy:
I've just set up a solaris 10 build cluster with a bunch of v20z machines for use with dmake, but then realized that dmake hard-codes the use of rsh (the path /usr/bin/rsh shows up in one of the supporting binaries). My sysadmins don't allow the use of rsh. Setting up /usr/bin/rsh as a symlink to /usr/bin/ssh works, but golly, it's a hack, it's fragile, and it probably won't survive the occasional patch to rsh.
Does sun have any plans to allow dmake to use other connection mechanisms to spawn remote shells, like, for instance, ssh?
Alternatively, has anyone found a reasonable way to get dmake to use ssh that doesn't involve setting up a symlink?
Thanks much!

Thank you for your report about this problem. Yes, we have a
RFE (Request For Enhancement) to implement ssh support
in dmake. This is an excellent news that you were able to
get dmake work over ssh with a help of symlink! I can build
an experimental version for you, that will use rsh or ssh,
depending on the setting of an environment variable.
If you have an idea how to specify the "remote shell" - please,
let me kow.
Thanks,
Nik

Signall 11 when doing dmake on NFS mount.

Hello,
When I use dmake -j 20 on a local filesystem everything works fine. When I do this on a NFS mounted filesystem I get a scattering of errors, like the following, so I have to use make instead.
I am using Sunpro 5.3 on Solaris 8 sparc.
Compiling foo.cpp
>> Signal 11:
while processing CFETIManager.cpp at line 0.
*** Error code 1
dmake: Warning: Command failed for target `foo.o'

Thanks for the help, I have asked our sys admins for the patches to be installed.
I can email you the build.tr file if you like.
The first one is here
23208:     execve("/opt/WorkShop6.0/SUNWspro/bin/../WS6U2/bin/ccfe", 0x000661FC, 0x000677A8) argc = 55
23208:     argv: /opt/WorkShop6.0/SUNWspro/bin/../WS6U2/bin/ccfe -y-o
The second is here
23208:     resolvepath("/home/nmitchell/nmitchell_unix_release/DistributedDevelopment/eSpeedAPI/sdk/cfetp/SOLARIS8/SUNPRO53/15s/sparc/CFETPRoutableMessage.o", "/home/nmitchell/nmitchell_unix_release/DistributedDevelopment/eSpeedAPI/sdk/cfetp/SOLARIS8/SUNPRO53/15s/sparc/CFETPRoutableMessage.o", 1024) = 132
23208:     Incurred fault #6, FLTBOUNDS %pc = 0x0038C230
23208:     siginfo: SIGSEGV SEGV_MAPERR addr=0xFF08C000
23208:     Received signal #11, SIGSEGV [caught]
23208:     siginfo: SIGSEGV SEGV_MAPERR addr=0xFF08C000
23208:     sigaction(SIGSEGV, 0xFFBECED8, 0xFFBECF58)     = 0
23208:     sigaction(SIGINT, 0xFFBECED8, 0xFFBECF58)     = 0
23208:     sigaction(SIGQUIT, 0xFFBECED8, 0xFFBECF58)     = 0
23208:     sigaction(SIGILL, 0xFFBECED8, 0xFFBECF58)     = 0
23208:     sigaction(SIGABRT, 0xFFBECED8, 0xFFBECF58)     = 0
23208:     sigaction(SIGFPE, 0xFFBECED8, 0xFFBECF58)     = 0
23208:     sigaction(SIGBUS, 0xFFBECED8, 0xFFBECF58)     = 0
23208:     sigaction(SIGTERM, 0xFFBECF38, 0xFFBECFB8)     = 0
23208:     unlink("/home/nmitchell/nmitchell_unix_release/DistributedDevelopment/eSpeedAPI/sdk/cfetp/SOLARIS8/SUNPRO53/15s/sparc/SunWS_cache/CC_lockfile") = 0
23208:     write(2, " > > S i g n a l 1".., 15)     = 15
23208:     write(2, " w h i l e p r".., 62)     = 62
23208:     sigaction(SIGSEGV, 0xFFBECE08, 0xFFBECE88)     = 0
23208:     sigaction(SIGINT, 0xFFBECE08, 0xFFBECE88)     = 0
23208:     sigaction(SIGQUIT, 0xFFBECE08, 0xFFBECE88)     = 0
23208:     sigaction(SIGILL, 0xFFBECE08, 0xFFBECE88)     = 0
23208:     sigaction(SIGABRT, 0xFFBECE08, 0xFFBECE88)     = 0
23208:     sigaction(SIGFPE, 0xFFBECE08, 0xFFBECE88)     = 0
23208:     sigaction(SIGBUS, 0xFFBECE08, 0xFFBECE88)     = 0
23208:     sigaction(SIGTERM, 0xFFBECE68, 0xFFBECEE8)     = 0
23208:     llseek(0, 0, SEEK_CUR)                    = 180281
23208:     _exit(1)

Anyony has dmake and Sun Grid Engine experience ?

Here is my another try to ask for the sharing of using dmake with SGE experience.
Did anyone successfully using dmake+SGE to see compilation performance gain ?
My orginal post at
http://www.opensolaris.org/jive/thread.jspa?messageID=8298&#8298
Thanks for your time and sharing
tj

We (development team) have created performance tests to compare
build performance in parallel, distributed and grid modes. Unfortunately
our grid is very small - it consists of 1 system, and in this case dmake
works twice faster in distributed mode, than in grid mode. But there is
no limitation in our implementation of grid mode in dmake, so if a build
has enough independent targets, and there is a large grid system - it will
definitely win.
Thanks,
Nikolay Molchanov

Installing Sun Studio 12 on Ubuntu 8.04

When I try to install Sun Studio 12 with the graphical installer, I get a message half was through that Java is not installed. In my case Sun's Java was already installed. I tell the Sun Studio installer to do the update and it finished what it was doing. After the install is done, I found that the Sun Studio executable is missing, so it looked like the installation did not work. What version of Java is Sun Studio expecting and does it need to be tied to a specific path? Is there a known method for installing Java for Sun Studio 12?
After this I uninstalled Java and Netbeans and started the system prep tool, which correctly said I was missing netbeans and java. I had the system prep tool install netbeans successfully but I get this message when trying to install java:
error: Failed dependencies:
glibc >= 2.1.2-11 is needed by jdk-1.5.0_09-fcs.i586
sh-utils >= 2.0-1 is needed by jdk-1.5.0_09-fcs.i586
fileutils >= 4.0-8 is needed by jdk-1.5.0_09-fcs.i586
gawk >= 3.0.4-1 is needed by jdk-1.5.0_09-fcs.i586
textutils >= 2.0-2 is needed by jdk-1.5.0_09-fcs.i586
/bin/sh is needed by jdk-1.5.0_09-fcs.i586
Any suggestions?

I could not find any log files with error information from Express or Sun Studio 12. Any ideas?Not yet :-) Can you try to build and debug a sample project? Does it show the same problem?
I mean one of several sample projects, that are shipped with the Sun Studio IDE.
Start "sunstudio", from main menu: "File->New Project", select Samples->C/C++/Fortran->Welcome
Did you try to run compilers and other tools?
Please, make sure they work. For example, run the following commands:
cc -V
CC -V
f90 -V
collect -V
dbx -V
dmake -v
(Note: the last one is small "v")

Studio 12 DBX internal error while memcheck is on.

bash-3.00$ dbx -xexec32
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
(dbx) -rwxr-xr-x 1 orbit osgrp1 1.2M Dec 26 17:18 <my_processnmae>
-rwxr-xr-x: not found
(dbx) dbxenv mt_sync_tracking off
(dbx) attach 6792 <this is pid>
Reading <my_processname>
Reading ld.so.1
Reading librtc.so
Reading libmapmalloc.so.1
Reading libcurses.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libelf.so.1
Reading libcrypt_i.so.1
Reading libpthread.so.1
Reading libdl.so.1
Reading librt.so.1
Reading libc.so.1
Reading libgen.so.1
Reading libaio.so.1
Reading libmd5.so.1
Reading libc_psr.so.1
Reading library_name**
Reading library_name**
Attached to process 6792 with 3 LWPs
t@1 (l@1) stopped in soaccept at 0xff040314
0xff040314: soaccept+0x0004: ta %icc,0x00000008
Current function is Tcp_receive
284 if ((th_data->sockfd = accept (sockfd, (struct sockaddr *)&clientaddr,&length)) == -1)
(dbx) check -access
access checking - ON
RTC: Enabling Error Checking...
RTC: Running program...
(dbx) cont
RTC: internal RTC error -- disabling Error Checking file: rtc_heap_map.c line: 697
^Ct@2 (l@2) signal INT (Interrupt) in ___sigtimedwait at 0xff040220
0xff040220: ___sigtimedwait+0x0004: ta %icc,0x00000008
Current function is sig_thr
1256 sigwait (&glb_sigact, &signal_alr);
(dbx) version
Machine hardware: sun4u
OS version: 5.10
Processor type: sparc
Hardware: SUNW,Sun-Fire-280R
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 "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_sparc 2007/05/03
any Idea ?
am i doing something wrong here. ? I want to check memory leak. ?
-Raxit

With hope if its bug, below may helpful.
(dbx) (dbx) (dbx) quit
detaching from process 6792
dbx: internal warning: function (__rtc_release_heap_region) called too early (preloading)
t@3 (l@3) signal SEGV (no mapping at the fault address) in _sleep at 0xff0330f0
0xff0330f0: _sleep+0x0078: ldsb [%o3 - 3005], %o2
Current function is scansessionisam_thr
1362 sleep (cfg_sec_shm_scantime); /*SCF no 10750 */
execution completed, exit code is 4982056
dbx: internal warning: rtc: _syscall: failed
dbx: warning: librtc.so and dbx version mismatch; Error checking disabled
Check your installation of librtc.so.
dbx: internal warning: rtc: munmap of patch area of segment '/usr/lib/libmapmalloc.so.1' failed
dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmp
ls -lrAbort (core dumped)
bash-3.00$ pstack /tmp/core
core '/tmp/core' of 6794: dbx -xexec32
ff1c0f90 lwpkill (6, 0, ff1a4a98, ffffffff, ff1e8284, 6) + 8
ff13ff98 abort (0, 1, 377d74, a83f0, ff1eb298, 0) + 110
000b5bf8 ???????? (b, 3c4400, 4575a1, 38b1f4, 37eabe, 1)
ff1bfec8 __sighndlr (b, ffbff408, ffbff150, b59ec, 0, 1) + c
ff1b4ff4 call_user_handler (b, 0, 8, 0, ff252000, ffbff150) + 3b8
001aef98 __1cGRtcMgrShandle_proc_detach6M_v_ (47d670, 5dd2a8, 38, 396000, 4c0498, 38) + d8
0018f850 __1cEProcGdetach6Mbbbb_v_ (4c0468, 467400, 466400, 0, 3ae2ac, 0) + 19c
000b8c68 ???????? (47e6f8, 0, 0, 0, 0, 1)
00289d94 __1cMpdksh_c_exit6FpnGInterp_ippcpv_i_ (47e6f8, 0, 876890, 0, 0, 466000) + a8
0015fbf4 ???????? (47e6f8, 1, 876890, 0, 877b78, 0)
002857a0 ???????? (47e6f8, 877b78, 877b58, 876890, 0, 467708)
0028468c __1cNpdksh_execute6FpnGInterp_pnCop_i_i_ (47e6f8, 49bab8, 0, 277c50, 47e6f8, 38b1f4) + 194
002735e0 __1cLpdksh_shell6FpnGInterp_pnGSource__i_ (47e6f8, 49e098, 465628, 446f54, 3d9625, 3d962c) + 46c
000b90d4 __1cNmain_cmd_loop6FpnGInterp__v_ (47e6f8, 37f400, 3ca2a4, 446f70, 3ca000, 3ca000) + 88
000b9e60 main (37e400, 0, 40, 47e6f8, 37f7c8, 1) + 750
000af268 _start (0, 0, 0, 0, 0, 0) + 108
bash-3.00$
bash-3.00$ dbx /opt/SunStudio12/
SUNWspro/ uninstall_Sun_Studio_12.class
bash-3.00$ dbx /opt/SunStudio12/SUNWspro/bin/dbx /tmp/core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading dbx
core file header read successfully
Reading ld.so.1
Reading libintl.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libdl.so.1
Reading libgen.so.1
Reading libw.so.1
Reading libm.so.1
Reading libc.so.1
Reading libc_psr.so.1
Reading libcpc.so.1
Reading libpctx.so.1
Reading libnvpair.so.1
Reading libdevinfo.so.1
Reading libproc.so.1
Reading librtld_db.so.1
Reading libelf.so.1
Reading libctf.so.1
program terminated by signal ABRT (Abort)
0xff1c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xff1c0fa0
(dbx) threads
dbx: thread related commands not available
(dbx) where
=>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xff1c0f90
[2] raise(0x6, 0x0, 0xff1a4a98, 0xffffffff, 0xff1e8284, 0x6), at 0xff15fd78
[3] abort(0x0, 0x1, 0x377d74, 0xa83f0, 0xff1eb298, 0x0), at 0xff13ff98
[4] 0xb5bf8(0xb, 0x3c4400, 0x4575a1, 0x38b1f4, 0x37eabe, 0x1), at 0xb5bf8
[5] __sighndlr(0xb, 0xffbff408, 0xffbff150, 0xb59ec, 0x0, 0x1), at 0xff1bfec8
---- called from signal handler with signal 11 (SIGSEGV) ------
[6] RtcMgr::handle_proc_detach(0x47d670, 0x5dd2a8, 0x38, 0x396000, 0x4c0498, 0x38), at 0x1aef98
[7] Proc::detach(0x4c0468, 0x467400, 0x466400, 0x0, 0x3ae2ac, 0x0), at 0x18f850
[8] 0xb8c68(0x47e6f8, 0x0, 0x0, 0x0, 0x0, 0x1), at 0xb8c68
[9] pdksh_c_exit(0x47e6f8, 0x0, 0x876890, 0x0, 0x0, 0x466000), at 0x289d94
[10] 0x15fbf4(0x47e6f8, 0x1, 0x876890, 0x0, 0x877b78, 0x0), at 0x15fbf4
[11] 0x2857a0(0x47e6f8, 0x877b78, 0x877b58, 0x876890, 0x0, 0x467708), at 0x2857a0
[12] pdksh_execute(0x47e6f8, 0x49bab8, 0x0, 0x277c50, 0x47e6f8, 0x38b1f4), at 0x28468c
[13] pdksh_shell(0x47e6f8, 0x49e098, 0x465628, 0x446f54, 0x3d9625, 0x3d962c), at 0x2735e0
[14] main_cmd_loop(0x47e6f8, 0x37f400, 0x3ca2a4, 0x446f70, 0x3ca000, 0x3ca000), at 0xb90d4
[15] main(0x37e400, 0x0, 0x40, 0x47e6f8, 0x37f7c8, 0x1), at 0xb9e60
(dbx)
-Raxit

Studio 12 rather unstable

~/src/apps/kmt/clamps> dbx ./clamps
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading clamps
Reading ld.so.1
Reading libuuid.so.1
Reading libsocket.so.1
Reading libxml2.so.2
Reading libresolv.so.2
Reading libnsl.so.1
Reading librt.so.1
Reading libstlport.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
Reading libpthread.so.1
Reading libz.so.1
Reading libaio.so.1
Reading libmd5.so.1
Reading libm.so.1
dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmp
Abort (core dumped)
version of "/opt/studio/12/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_i386 2007/05/03
version of "/opt/studio/12/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_i386 2007/05/03
version of "/opt/studio/12/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_i386 2007/05/03
version of "/opt/studio/12/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_i386 2007/05/03
version of "/opt/studio/12/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_i386 2007/05/03
version of "/opt/studio/12/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_i386 2007/05/03
I must say that Sun really needs to do something about dbx and fbe stability. The code is probably unchanged from the days of Forte and it shows. It has been unstable and prone to segfaults, strange symbol table malfunctioning/misreadings and other annoyances since I can remember using it. I've used dbx since the RWCString days of Forte 4.2 and every release in between at several different firms on several different hardware platforms and every version of Solaris since it was called SunOS and every single one of them experienced the same pattern of problems with dbx. Several simply switched to g++/gdb, reasoning that optimized binaries are worth very little when a slight change to a template can result in your binary becoming unreadable by dbx, often times unnoticed by you until it is far too late and you have a
The linker too seems to be very quirky and sometimes downright unreliable. I feel like if I have the audicity to write a C++ template longer than a few lines, either fbe, dbx, CC or several of them may crash at any point during the developmet process or, heaven forbid, when you need to debug a production core file.
My problems started yesterday when I decided to upgrade to Studio 12 after seeing that it was supposedly more compatible with boost, especially the latest 1.34 release. Those hopes were soon dashed as one out of every two random build variances combinations appear to cause either CC or the linker to seg fault. Apparently, this is a known issue which I was able to work around by lowering the optimization level from -x04 to -x01.
Now, it appears a couple of my binaries built by studio 12 are simply undebuggable by studio 12. The irony of course is the least stable tool in sun studio is the debugger.
I apologize for the complaining as I am quite frustrated at the moment. I love studio for its optimizing but simply having the piece of mind that the debugger will work when needed would be lov

(dbx) proc -map
Loadobject mappings for current core file:
0x0000000100000000 /opt/studio/12/SUNWspro/prod/bin/sparcv9/dbx
Warning: checksum in file(cb35) doesn't match image(71a4)
0xffffffff7f500000 /lib/sparcv9/libintl.so.1
is being filtered by: libc.so.1
0xffffffff7f200000 /lib/sparcv9/libnsl.so.1
0xffffffff7ef00000 /lib/sparcv9/libsocket.so.1
0xffffffff7ed00000 /lib/sparcv9/libdl.so.1
is being filtered by: /usr/lib/sparcv9/ld.so.1
0xffffffff7eb00000 /lib/sparcv9/libgen.so.1
0xffffffff7f400000 /lib/sparcv9/libw.so.1
is being filtered by: libc.so.1
0xffffffff7e700000 /lib/sparcv9/libm.so.1
is being filtered by: libm.so.2
0xffffffff7e500000 /lib/sparcv9/libc.so.1
0xffffffff7e400000 /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
0xffffffff7dd00000 /usr/lib/locale/en_US.UTF-8/sparcv9/en_US.UTF-8.so.3
0xffffffff7db00000 /usr/lib/locale/common/sparcv9/methods_unicode.so.3
0xffffffff7d900000 /usr/lib/sparcv9/libcpc.so.1
0xffffffff7d700000 /usr/lib/sparcv9/libpctx.so.1
0xffffffff7d400000 /lib/sparcv9/libnvpair.so.1
0xffffffff7d200000 /lib/sparcv9/libdevinfo.so.1
0xffffffff7d000000 /lib/sparcv9/libproc.so.1
0xffffffff7cd00000 /lib/sparcv9/libsec.so.1
0xffffffff7cb00000 /lib/sparcv9/librtld_db.so.1
0xffffffff7c900000 /lib/sparcv9/libelf.so.1
0xffffffff7c700000 /lib/sparcv9/libctf.so.1
0xffffffff7c400000 /lib/sparcv9/libavl.so.1
0xffffffff7c100000 /lib/sparcv9/libc_db.so.1
0xffffffff7f600000 /lib/sparcv9/ld.so.1 [LM_ID_LDSO]
core file address ranges:
0x0000000000010000 - 0x0000000000367c97 (text)
0x0000000100000000 - 0x0000000100400000 (data)
0x0000000100400000 - 0x0000000100406000 (data)
0x0000000100504000 - 0x00000001005e0000 (data)
0x00000001005e0000 - 0x0000000100800000 (data)
0x0000000100800000 - 0x0000000103000000 (data)
0xffffffff7c100000 - 0xffffffff7c108000 (data)
0xffffffff7c100000 - 0xffffffff7c106172 (text)
0xffffffff7c208000 - 0xffffffff7c20a000 (data)
0xffffffff7c400000 - 0xffffffff7c401078 (text)
0xffffffff7c400000 - 0xffffffff7c402000 (data)
0xffffffff7c502000 - 0xffffffff7c504000 (data)
0xffffffff7c600000 - 0xffffffff7c602000 (data)
0xffffffff7c700000 - 0xffffffff7c70c000 (data)
0xffffffff7c700000 - 0xffffffff7c70a97f (text)
0xffffffff7c80c000 - 0xffffffff7c80e000 (data)
0xffffffff7c900000 - 0xffffffff7c91e000 (data)
0xffffffff7c900000 - 0xffffffff7c91c6ad (text)
0xffffffff7ca1e000 - 0xffffffff7ca20000 (data)
0xffffffff7cb00000 - 0xffffffff7cb06000 (data)
0xffffffff7cb00000 - 0xffffffff7cb0479c (text)
0xffffffff7cc06000 - 0xffffffff7cc08000 (data)
0xffffffff7cd00000 - 0xffffffff7cd11069 (text)
0xffffffff7cd00000 - 0xffffffff7cd12000 (data)
0xffffffff7ce12000 - 0xffffffff7ce18000 (data)
0xffffffff7ce18000 - 0xffffffff7ce1c000 (data)
0xffffffff7cf00000 - 0xffffffff7cf02000 (data)
0xffffffff7d000000 - 0xffffffff7d026c99 (text)
0xffffffff7d000000 - 0xffffffff7d028000 (data)
0xffffffff7d128000 - 0xffffffff7d12c000 (data)
0xffffffff7d200000 - 0xffffffff7d21a71d (text)
0xffffffff7d200000 - 0xffffffff7d21c000 (data)
0xffffffff7d31c000 - 0xffffffff7d320000 (data)
0xffffffff7d400000 - 0xffffffff7d408000 (data)
0xffffffff7d400000 - 0xffffffff7d406d3a (text)
0xffffffff7d508000 - 0xffffffff7d50a000 (data)
0xffffffff7d600000 - 0xffffffff7d602000 (data)
0xffffffff7d700000 - 0xffffffff7d703238 (text)
0xffffffff7d700000 - 0xffffffff7d704000 (data)
0xffffffff7d804000 - 0xffffffff7d806000 (data)
0xffffffff7d900000 - 0xffffffff7d909385 (text)
0xffffffff7d900000 - 0xffffffff7d90a000 (data)
0xffffffff7da0a000 - 0xffffffff7da0c000 (data)
0xffffffff7db00000 - 0xffffffff7db10000 (data)
0xffffffff7db00000 - 0xffffffff7db0eb21 (text)
0xffffffff7dc0e000 - 0xffffffff7dc10000 (data)
0xffffffff7dd00000 - 0xffffffff7df22000 (data)
0xffffffff7dd00000 - 0xffffffff7df2175a (text)
0xffffffff7e020000 - 0xffffffff7e024000 (data)
0xffffffff7e100000 - 0xffffffff7e102000 (data)
0xffffffff7e130000 - 0xffffffff7e132000 (data)
0xffffffff7e200000 - 0xffffffff7e210000 (data)
0xffffffff7e300000 - 0xffffffff7e302000 (data)
0xffffffff7e400000 - 0xffffffff7e402000 (data)
0xffffffff7e400000 - 0xffffffff7e400d6c (text)
0xffffffff7e500000 - 0xffffffff7e5e41f5 (text)
0xffffffff7e500000 - 0xffffffff7e5e6000 (data)
0xffffffff7e6e6000 - 0xffffffff7e6f6000 (data)
0xffffffff7e6f6000 - 0xffffffff7e6f8000 (data)
0xffffffff7e700000 - 0xffffffff7e706000 (data)
0xffffffff7e700000 - 0xffffffff7e704758 (text)
0xffffffff7e804000 - 0xffffffff7e806000 (data)
0xffffffff7e900000 - 0xffffffff7e906000 (data)
0xffffffff7ea00000 - 0xffffffff7ea02000 (data)
0xffffffff7eb00000 - 0xffffffff7eb0619d (text)
0xffffffff7eb00000 - 0xffffffff7eb08000 (data)
0xffffffff7ec08000 - 0xffffffff7ec0a000 (data)
0xffffffff7ed00000 - 0xffffffff7ed02000 (data)
0xffffffff7ed00000 - 0xffffffff7ed00773 (text)
0xffffffff7ee02000 - 0xffffffff7ee04000 (data)
0xffffffff7ef00000 - 0xffffffff7ef0e000 (data)
0xffffffff7ef00000 - 0xffffffff7ef0cdc2 (text)
0xffffffff7f00e000 - 0xffffffff7f012000 (data)
0xffffffff7f100000 - 0xffffffff7f102000 (data)
0xffffffff7f200000 - 0xffffffff7f2ab872 (text)
0xffffffff7f200000 - 0xffffffff7f2ac000 (data)
0xffffffff7f3ac000 - 0xffffffff7f3bc000 (data)
0xffffffff7f3bc000 - 0xffffffff7f3c4000 (data)
0xffffffff7f400000 - 0xffffffff7f4010e4 (text)
0xffffffff7f400000 - 0xffffffff7f402000 (data)
0xffffffff7f500000 - 0xffffffff7f5004ce (text)
0xffffffff7f500000 - 0xffffffff7f502000 (data)
0xffffffff7f600000 - 0xffffffff7f633056 (text)
0xffffffff7f600000 - 0xffffffff7f634000 (data)
0xffffffff7f600000 - 0xffffffff7f633c4a (text)
0xffffffff7f734000 - 0xffffffff7f738000 (data)
0xffffffff7f738000 - 0xffffffff7f73a000 (data)
0xffffffff7fff8000 - 0xffffffff80000000 (data)

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

How to fix aSun Studio 9 bug running on a Solaris 10 ?

Hi all
I have Sun Studio 9 installed on a Sun Solaris 10 and when I try to run the debug tools I receive this Issue
(dbx) cd /users/****/ISMD_V10_integration/MMI/IHM/SCHEMA/bin
(dbx) debug /users/***/ISMD_V10_integration/MMI/IHM/SCHEMA/bin/dbtool.Solaris
Reading dbtool.Solaris
Reading ld.so.1
dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmpSo I tried to install this Patch [1186876|http://sunsolve.sun.com/search/document.do?assetkey=1-21-118676] .
This is what I received
# patchadd 118676-02
Validating patches...
Loading patches installed on the system...
Done!
Loading patches requested to install.
Cannot open pkginfo file /users/spiteri/118676-02/SUNWxcu4t/pkginfo
Done!
Checking patches that you specified for installation.
Done!
The following requested patches will not be installed because
they have been made obsolete by other patches already
installed on the system or by patches you have specified for installation.
           0 All packages from patch 118676-02 are patched by higher revision patches.
No patches to install.More over when I checked if the patch exist I have this
# showrev -p | grep 118676
Patch: 118676-03 Obsoletes: Requires: Incompatibles: Packages: SUNWsprot, SUNWxcu4tThen I checked the DBX version
# dbx
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.3' in your .dbxrc
(dbx) version
Machine hardware:   sun4u
OS version:         5.10
Processor type:     sparc
Hardware:           SUNW,Sun-Fire-280R
The following components are installed on your system:
Sun Studio 9
        Sun Studio 9 C Compiler
        Sun Studio 9 C++ Compiler
        Sun Studio 9 Tools.h++ 7.1
        Sun Studio 9 C++ Standard 64-bit Class Library
        Sun Studio 9 Garbage Collector
        Sun Studio 9 Fortran 95
        Sun Studio 9 Debugging Tools (including dbx)
        Sun Studio 9 Debugger GUI
        Sun Studio 9 Performance Tools (including collect, ...)
        Sun Studio 9 X-Designer
        Sun Studio 9 VIM editor
        Sun Studio 9 XEmacs editor
        Sun Studio 9 Native Connector Tool
        Sun Studio 9 LockLint
        Sun Studio 9 Building Software (including dmake)
        Sun Studio 9 Documentation Set
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
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.0 2004/07/15
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.3 2004/07/15
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Performance Analyzer 7.3 2004/07/15
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.5 2004/07/15And to conclude I tried this
pstack core | c++filt
core 'core' of 15779:   /opt/SUNWspro/bin/../prod/bin/sparcv9/dbx -g sync,stdio -c dbxenv supp
ffffffff7e8d3894 _lwp_kill (6, 0, ffffffff7e8b5dd4, ffffffffffffffff, ffffffff7e9ec000, 0) + 8
ffffffff7e84a5ec abort (1, 1b8, 0, 1a1b20, 0, 0) + 118
00000001000b4204 ???????? (1005fd, 100400, a, 100400, 10060b000, 100512e30)
ffffffff7e8d2798 __sighndlr (a, ffffffff7fffb7d0, ffffffff7fffb4f0, 1000b3f30, 0, 9) + c
ffffffff7e8c6a04 call_user_handler (ffffffff7e700200, ffffffff7e700200, ffffffff7fffb4f0, 8, 0, 0) + 3e0
ffffffff7db19b30 Pgetauxval (1012eae48, 7e3, ffffffff7f736c60, ffffffff7f61c5bc, 6f723c636861723e, 7e3) + 38
ffffffff7db0b12c Pbrandname (1012eae48, ffffffff7fffbfc0, 400, 0, ffffffff7f736c60, 821) + 8
ffffffff7db185a0 ps_pbrandname (1012eae48, ffffffff7fffbfc0, 400, 1001afee0, ffffffff7d806000, 1) + c
ffffffff7d701bfc _rd_reset32 (7e0, ffffffff7d806000, ffffffff7d806000, 100691860, ffffffff7d806000, 1) + 488
ffffffff7d700df0 rd_reset (1011f0540, 0, 1052ac, ffffffff7e8c88f4, 1, 0) + a8
ffffffff7d700eb8 rd_new (1012eae48, ffffffff7cf00160, 1025a6b40, 0, ffffffff7d806000, ffffffff7d806000) + a8
00000001003146e0 void RtldAgent::open(Pcs*,const ps_prochandle*) (101789570, 10062a180, 1012eae48, 100558, 1, ffffffff7d700e10) + 68
00000001001acbec ???????? (1012aec40, 0, 100691cf0, 10053dd33, 10053d000, ffffffff7fffc6e0)
00000001001addd4 Proc*ProcMgr::start(Target*,bool,bool,bool) (100512e30, 0, 100627a50, 0, 1012aec40, 10053e18e) + 92c
0000000100171bb8 int do_run(Interp*,bool,Level_e) (100400, 10053b000, 100400, 100512e30, 1, 100400) + 19c
00000001002abf28 ???????? (10056b477, 1025a7890, 10062b638, 0, 100642750, 10068ec70)
00000001002aac18 int pdksh_execute(Interp*,op*,int) (10062b5f0, 100643740, 0, 10062b5f0, 103084180, 101339a10) + 1c0
000000010029746c int pdksh_shell(Interp*,Source*) (10062b5f0, 102703bd0, 3, 100569df9, 100569e00, 1000b3c10) + 4c0
0000000100296eac int pdksh_command(Interp*,const char*) (ffffffffffffffff, 0, 1, 1, 10062b5f0, 10066bb40) + 88
00000001001523e0 void MyServantDbx::ksh_cmd(int,unsigned,const char*) (1006604e0, 0, 0, 1025a7714, 10052a, 10060c3f0) + 98
00000001002d82e4 bool Dispatcher::dispatch(ProtoReceiver*,MsgRcv*) (1002c1b4c, 1006604e0, ffffffff7fffd278, 1002c1b4c, 100000, 0) + 100
00000001002d4968 void Messenger::handle_message_help(AuthStyle,MsgRcv&) (1006604e0, 0, ffffffff7fffd278, 10056f358, 10056f000, 1002c8498) + a4
00000001002d46dc void Messenger::handle_message(AuthStyle) (1006604e0, 0, 0, ffffffff7fffd278, 10052b0d0, 100000) + dc
00000001002c87ac void Servant::cb_message(int,unsigned short,void*) (b, 10052b0d0, 1006604e0, 1003e3000, 1003e3, 100000) + 8c
00000001002c3ed4 void CBInfo::dispatch(int,unsigned short) (100625bc0, 10056f, 1003e1687, b, 100400, 1) + ac
00000001002c4304 void Notifier::invoke(int,unsigned short,CbData*) (10065f0b0, b, 1, 100625bc0, 1002c8721, 1002c3e28) + 18
00000001002c4b88 void NotifierDirect::dispatch_help(int,unsigned short,CBInfo*,bool*) (10065f0b0, b, 100400, 100625bc0, ffffffff7fffda2f, 1000000000000) + c4
00000001002c51ac bool NotifierPoll::dispatch(bool*) (10065f0b0, ffffffff7fffda2f, ffffffff7fffd630, 18, 1003e1d7c, ffffffff7fffd770) + 27c
00000001002c4d0c void NotifierDirect::loop(bool*) (10065f0b0, ffffffff7fffda2f, 1003e1, 10056eeb8, 100000, 1003e1b89) + 9c
000000010014fd0c ???????? (10062b5f0, ffffffff7fffdb1c, 100400, 10052a5b3, 100512e30, 10052a)
000000010029e874 ???????? (10062b5f0, 100400, 10056a69d, 0, 10066bb40, 1)
000000010029c888 int yylex(Interp*,int) (10062b5f0, 9, 0, 0, 10062b830, ffffffff7fffdc5c) + 220
000000010029a3fc int yyparse(Interp*) (10062b5f0, 100400, ffffffff7fffddd8, 0, 0, 1) + 18
000000010029c5c4 op*compile(Interp*,Source*) (10062b5f0, 10066bb40, 64, 100506000, 10062b798, 10066bbc8) + 28
00000001002972a8 int pdksh_shell(Interp*,Source*) (10062b5f0, 10066bb40, 100400, 100569df9, 100569e00, 1000b3c10) + 2fc
00000001000b817c void main_cmd_loop(Interp*) (10062b5f0, 100400, 100507c50, 1005e52e8, 100555400, 100507) + a8
00000001000b91ac main (100400, 100506, 100507c50, 10062b5f0, 100512e30, 1) + b8c
00000001000b1e3c _start (0, 0, 0, 0, 0, 0) + 17cSo can someone help me please ??

You are seeing 6477975, which is fixed in dbx patch 117564-07 (which is for sparc) and 117565-07 (for x86).
However, if you are already on Solaris 10, I'd recommend to upgrade to Sun Studio 12, which is free, has many improvements and works much better with Solaris 10. If you, for any reason, can't upgrade compilers to Studio 12, you can still use Sun Studio 12 IDE plus debugger and compilers from Studio 9. It is easy to install several versions of Sun Studio on a machine, you just need to give different base directories to the installer.

Auto generated code in makefile

For our product we have a TCL script that reads a series of text files and generates C++ classes for easy access to database records. Our code has been in use for make years and works very well. We have always used a solaris command prompt dmake to compile, which first generates the C++ files then complies them. It uses a series of enviroment variables which a user must set before compilation.
I recently tried to create a Sun Studio Express based on NetBeans 6.5.rc1 project from a make file. This has worked for every other makefile except for this one. The others do not have any auto generated code.
To run sun studio I in a command prompt source in the environments then run netbeans. Then I choose to build the product but I get an error. I then try to copy the command it is running into telnet window and it works fine. Does anyone have an idea on why in the sun studio I get and error while the telnet window works fine.

I think the problem is that the SunStudio IDE runs the build command in a wrong directory.
Can you verify that the working directory is correct?
(it is in project properties: Build > Make)
Also you can find this directory in the message in the output, when you try to build the project.
That's the message, that you copied to the terminal window.
Thanks,
Nik

How to include header files from different directories?

Hi,
Sorry for the newb question, but I can't figure this out. I'm trying to compile a simple piece of code (C++) that uses header files in a directory different from the Project directory; header files are in /opt/csw/postgresql/include/pqxx. I've tried a few different things, adding that directory to the include directives under Resource Files, add existing files from a folder, etc etc. Whenever I try to build, dmake bails with status -1. I can't seem to get this working, can someone explain how to use header files from different directories?
Thanks,
SlowToady

Header files are usually specified relative to a base directory. If the base directory is not a system directory -- /usr/include or the compiler installation directory -- add a command-line directive
-I path/to/base/dirfor each such directory.
The path can be absolute, such as
-i /opt/csw/postgresql/includeor relative, such as
-I ../../my/includeIn your source code, specify the header file relative to the base directory, and be sure to use quotes, not angle brackets. Example:
#include "header.h" // right
#include <header.h> // wrongThe angle brackets are used for system headers, like <iostream> or <stdlib.h>.
The rules above are common to all compilers on Unix and Linux, and generally to all C and C++ compilers.
For more details, read about the -I option in the C++ Users Guide. You can find the guide by pointing your browser to the "docs" directory in the compiler installation, or go here:
http://docs.sun.com/app/docs/doc/819-5267
All command-line options are described in Appendix A.

Warning: Variable in inherited class hides private variable in base class?

Hello,
I've come across a simple case like this:
class A {
private:
int varA;
class B : public A {
B() {
int varA = 5; // does it hide A::varA ?!
};which is causing my Studio 11/12 compiler front ends to issue a warning like:
"..., line 8: Warning: varA hides A::varA."
when I try to compile with default settings.
I'm aware that this warning can be easily worked around, but I'm still wondering what the standard says about this?
Does B::varA really hide A::varA even though it is declared private?!
Looks like a small bug to me.
Can someone please try my example with the latest and greatest Studio compiler?
Thanks,
Jochen
Compiler details:
# /usr/sunstudio12.1/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 update 1
Sun Studio 12 update 1 C Compiler
Sun Studio 12 update 1 C++ Compiler
Sun Studio 12 update 1 Tools.h++ 7.1
Sun Studio 12 update 1 C++ Standard 64-bit Class Library
Sun Studio 12 update 1 Garbage Collector
Sun Studio 12 update 1 Debugging Tools (including dbx)
Sun Studio 12 update 1 IDE
Sun Studio 12 update 1 Performance Analyzer (including collect, ...)
Sun Studio 12 update 1 Performance Library
Sun Studio 12 update 1 Scalapack
Sun Studio 12 update 1 LockLint
Sun Studio 12 update 1 Building Software (including dmake)
Sun Studio 12 update 1 Documentation Set
version of "/usr/sunstudio12.1/bin/../prod/bin/../../bin/cc": Sun C 5.10 SunOS_i386 Patch 142363-03 2009/12/03
version of "/usr/sunstudio12.1/bin/../prod/bin/../../bin/CC": Sun C++ 5.10 SunOS_i386 128229-04 2009/11/25
version of "/usr/sunstudio12.1/bin/../prod/bin/../../bin/dbx": Sun DBX Debugger 7.7 SunOS_i386 2009/06/03
version of "/usr/sunstudio12.1/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.7 SunOS_i386 2009/06/03
version of "/usr/sunstudio12.1/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.9 SunOS_i386 2009/06/03

jroemmler wrote:
Steve_Clamage wrote:
Accessibility versus visibility is part of the standard. [...]Ok, If that's the case, then the warning is caused by design and not by Studio C++.Yes, sort of.
>
I assume that other compilers do not complain because they do not strictly adhere to the standard and perform additional accessibility checks before complaining about a name clash...No. Hiding a name is legal, and your code example has well-defined behavior. There is no issue that a compiler is required to complain about. (That is, no language rule is violated.)
If name hiding results in an invalid program, the error is due to the effects of hiding the name, not the hiding itself. Having a warning about the name hiding would help you find the reason for the error in that case.
The C++ standard requires a "diagnostic message" for most violations of rules. Compilers generally treat these violations as fatal errors. The standard does not require or forbid any other kind of diagnostic message. That leaves compiler implementers free to emit, or omit, any warnings they think will best serve their customers.
Compilers vary in what sorts of warnings (non-fatal observations) they emit. Most compilers, including Studio C++, provide ways to control the kinds of warnings you see. Compilers that don't warn by default about name hiding might provide a warning if you ask for it. For example, Studio C++ offers these options to control warnings:
-w Do not emit any warnings
+w Emit additional warnings
+w2 Emit still more warnings about picky portability issues
-errtags Emit a tag with warnings for use with -erroff and -errwarn
-erroff=... Do not issue the listed warnings
-errwarn=... Treat the listed warnings as errors
-xwe Treat all warnings as errors
You can read more about these options in the C++ Users Guide.

Dmake -j

Similar Messages

Maybe you are looking for