Sun Studio and Solaris integration

Now that Sun Studio is free, we’re trying to get it installed more seamlessly with Solaris in time for Solaris 10 update 2.  Ooops.  Scratch that, “update 2” is an internal name.  The external name would be “Solaris 10 0X06” with some month number for X.  Don’t ask me, it wasn’t my idea.  Anyway, one thing we want to do is get the compilers and tools on everyone’s default path by adding symlinks in /usr/bin.

Of course when this idea was thunk up, the thinker didn’t realize that we have about 100 executables in the Sun Studio bin directory. (Not to mention the 2084 man pages, mostly for library routines).  That’s a lot of symlinks. It would be nice to get ‘gvim’ and ‘xemacs’ on everyone’s path by default, even if they aren’t a big Sun Studio fan. And it would be nice to help prevent the /usr/ucb/cc problem. Having a ‘cc’ command in /usr/bin would help.

One of the reasons for this is that Linux has gcc, gdb, g++ etc on the default search path, and it really makes sense for Solaris to offer the support for building software. Configure scripts are used to just ‘finding’ the right tools on your search path. 

For now, all the developer tools would be a separate DVD which is optional to install. So this isn’t going to be inflicted on everyone, at least for now.

So just for grins, here’s the list of things in the ‘bin’ directory for Sun Studio 11:

CC
CCadmin
analyzer
ats
ats_server
b2m
bcheck
bil2xd
binopt
bit
c++filt
c89
c99
cb
cc
cc-5.0
cflow
checkjava
collect
cscope
ctc
ctcr
ctrace
cxref
dbx
dem
dem_dbx
dem_ref
dmake
dumpstabs
dwarfdump
ellcc
er_archive
er_bit
er_cp
er_export
er_html
er_kernel
er_mv
er_print
er_rm
er_rock
er_src
er_trace
etags
f77
f90
f95
fbe
fbe-4.0
fdumpmod
fpp
fpr
fpversion
fsplit
gil2xd
gnuattach
gnuclient
gnudoit
gvim
indent
libsunperf_check
lint
lock_lint
ootags
ptclean
rcs-checkin
rtc_patch_area
rxm
rxs
sbcleanup
sbenter
sbquery
sbtags
smallxd
smctl
sparcv9
spot
ss_attach
sunstudio
tcov
uil2xd
version
version-5.0
visu
visuroot
whatdir
xdcapture
xdconfig
xdesigner
xdhelp
xdrecord
xdreplay
xdroot
xdtosj
xemacs
xemacs-mule

 

Comments:

Why not add the location of the studio compilers to the potential PATH when it's installed?

usepackage and similar things work well for this and make customization easy (e.g. to support multiple versions of tools).

Posted by Tony on April 14, 2006 at 12:56 AM PDT #

Not all of our users will be using a utility like usepackage. We need a scheme that works for everyone. Many people put code in their start up files that assigns to PATH and overwrites any previous settings, so adding something to PATH in the system-wide start up files won't work a lot of the time.

Posted by Chris Quenelle on April 17, 2006 at 09:04 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Chris Quenelle

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today