The more I know about SPARC the more I like it.
Originally, there were something else than just about money.
Today we have the clear indication of key Oracle application features going into the silicon.
I hope all this is kept as "extensions" that don't cripple the original spirit of SPARC.
Here are some of my favorite "historical" videos:
Thursday, November 22, 2012
Tuesday, November 6, 2012
Solaris Studio 12.3 installation
The best way to install Oracle Solaris Studio is to set up a local IPS repository.
After the above activities are completed, the installation is very easy:
It's important to adjust the PATH and MANPATH environment variables.
At some point on .profile add the following lines:
All this is very simple and we can start coding and compiling right away.
Nevertheless, I would highly recommend using a remote build host.
After the above activities are completed, the installation is very easy:
# pkg install solarisstudio-123
It's important to adjust the PATH and MANPATH environment variables.
At some point on .profile add the following lines:
PATH=$PATH:/opt/solarisstudio12.3/bin
export PATH
MANPATH=${MANPATH:-/usr/man}:/opt/solarisstudio12.3/man
export MANPATHAll this is very simple and we can start coding and compiling right away.
Nevertheless, I would highly recommend using a remote build host.
IPS repository access
The procedure is well and fairly documented but I'll attempt an additional summary.
Once the IPS repository creation is done, an access method must be chosen.
Please, assume the creation settings according to the above link.
If the repository is to be used:
For the file based origin it's as simple as:
# pkg set-publisher -p /export/depot/studio
For the networked version, things are slightly more complicated.
If simply setting up HTTP(S) access to a Solaris repository just do:
# FMRI=pkg/server
# URI=http://depot-1/solaris
# svccfg -s $FMRI setprop pkg/inst_root = /export/depot/solaris
# svccfg -s $FMRI setprop pkg/readonly = true
# svccfg -s $FMRI setprop pkg/proxy_base = astring: $URI
# svccfg -s $FMRI setprop pkg/port = 80
# svccfg -s $FMRI setprop pkg/threads = 10
# svcadm refresh $FMRI
# svcadm enable $FMRI
# DEFAULT=http://pkg.oracle.com/solaris/release
# pkg set-publisher -G "$DEFAULT" -g "$URI" solaris
But if, in addition, for instance, also setting up HTTP(S) access to Solaris Studio repository, it will be necessary to set up an additional instance of the svc:/application/pkg/server SMF service. Note how the new instance, studio, just contains a few overrides.
# FMRI=pkg/server:studio
# svccfg -s $FMRI addpg pkg application
# svccfg -s $FMRI setprop pkg/inst_root = /export/depot/studio
# svccfg -s $FMRI setprop pkg/readonly = true
# svccfg -s $FMRI setprop pkg/proxy_base = astring: $URI
# svccfg -s $FMRI setprop pkg/port = 81
# svccfg -s $FMRI setprop pkg/threads = 10
# svccfg -s $FMRI addpg general framework
# svccfg -s $FMRI addpropvalue general/complete astring: studio
# svccfg -s $FMRI addpropvalue general/enabled boolean: true
# svcadm refresh $FMRI
# svcadm enable $FMRI
# pkg set-publisher -g "$URI" solarisstudio
Once the IPS repository creation is done, an access method must be chosen.
Please, assume the creation settings according to the above link.
If the repository is to be used:
- Just within a single physical system, global zone and/or non-global zones:
It may be more efficient to use a file based origin (URI).
Non-global zones may inherit settings which is nice.
- By multiple physical systems or virtual machines, such as in remote building:
A network transport, such as HTTP or HTTPS is the best.
Note that you may also refer to http://localhost, of course.
For the file based origin it's as simple as:
# pkg set-publisher -p /export/depot/studio
For the networked version, things are slightly more complicated.
If simply setting up HTTP(S) access to a Solaris repository just do:
# FMRI=pkg/server
# URI=http://depot-1/solaris
# svccfg -s $FMRI setprop pkg/inst_root = /export/depot/solaris
# svccfg -s $FMRI setprop pkg/readonly = true
# svccfg -s $FMRI setprop pkg/proxy_base = astring: $URI
# svccfg -s $FMRI setprop pkg/port = 80
# svccfg -s $FMRI setprop pkg/threads = 10
# svcadm refresh $FMRI
# svcadm enable $FMRI
# DEFAULT=http://pkg.oracle.com/solaris/release
# pkg set-publisher -G "$DEFAULT" -g "$URI" solaris
But if, in addition, for instance, also setting up HTTP(S) access to Solaris Studio repository, it will be necessary to set up an additional instance of the svc:/application/pkg/server SMF service. Note how the new instance, studio, just contains a few overrides.
# FMRI=pkg/server:studio
# URI=http://depot-1/studio
# svccfg -s pkg/server add studio
# svccfg -s pkg/server add studio
# svccfg -s $FMRI addpg pkg application
# svccfg -s $FMRI setprop pkg/inst_root = /export/depot/studio
# svccfg -s $FMRI setprop pkg/readonly = true
# svccfg -s $FMRI setprop pkg/proxy_base = astring: $URI
# svccfg -s $FMRI setprop pkg/port = 81
# svccfg -s $FMRI setprop pkg/threads = 10
# svccfg -s $FMRI addpg general framework
# svccfg -s $FMRI addpropvalue general/complete astring: studio
# svccfg -s $FMRI addpropvalue general/enabled boolean: true
# svcadm refresh $FMRI
# svcadm enable $FMRI
# pkg set-publisher -g "$URI" solarisstudio
IPS repository creation
This post is about the first steps on establishing a a local IPS repository.
But once this is done establishing access to it is covered on a separate post.
In addition, after these previous tasks are complete, it may be necessary to update it.
For instance, the best way to install Oracle Solaris Studio is to set up a local IPS repository.
The procedure is reasonably well and fairly documented, but let's review it anyway.
What may not be very clear is that by default a local repository would be assumed to rest in /var/pkg/repo, even though it doesn't exist by default. This means that a dedicated ZFS dataset could or should have its mountpoint property set to this default, although it could be better to use symbolic links yielding something similar to /var/pkg/solaris/11.x/release and /var/pkg/solaris/11.x/sru-# and so on... But below, as dealing with Studio packages instead of OS packages, I've followed the crowd and created something completely apart. Anyway, note that in addition to compression (compression=on), access time could be turned off (atime=off) to buy some performance:
# zfs get -r compression rpool/export/depot
NAME PROPERTY VALUE SOURCE
rpool/export/depot compression off default
rpool/export/depot/studio compression on local
# pkgrepo create /export/depot/studio
# ll /export/depot/studio
...
-rw-r--r-- 1 root root 78 Nov 6 10:45 pkg5.repository
I'll use the support version of the repository which requires an Oracle support plan.
With no support plan the release version can be used according to terms and conditions.
For both versions it's necessary to get certificate(s) at https://pkg-register.oracle.com:
# cd /var/pkg/ssl
# ll Studio_Support.*
...
-rw------- 1 root root 753 ... Studio_Support.cert.pem
-rw------- 1 root root 887 ... Studio_Support.key.pem
I'll use an script to populate and later update the local repository. If behind a proxy, set http_proxy and https_proxy accordingly. But sometimes a proxy/firewall can block the several TCP connections from the remote port 443 to random ports and the symptoms are stalls or ugly messages. In case of difficulties check your command line, your certificates and then the proxy/firewall settings. Perhaps you may need to temporary alter your wired connection and temporarily bypass something.
But IPS repositories are not only useful for Solaris Studio.
In fact, it's crucial for Solaris 11 itself.
Start with just the initial release version of the repository.
Later, it can turn into a multiple support release updates repository.
The big picture is rather simple:
For obtaining the release packages, two methods are available.
As always, begin by creating a dedicated ZFS file system.
Ideally, set compression and atime properties as already described.
The release packages can be found at http://pkg.oracle.com/solaris/release.
Alternatively, download and concatenate a split ISO file.
I'm not sure which is the most efficient.
I do know that burning the ISO file, instead of lofs-mounting it is bad idea.
It'll take much longer to receive all the packages.
Underlying seek in optical media isn't efficient.
The manifests processing is specially awful.
Getting the release packages.
Choose one of the following options.
OPTION 1:
OPTION 2:
user 1m20.248s
sys 3m43.634s
NOTE
# zfs get referenced,compressratio rpool/export/depot/solaris
NAME PROPERTY VALUE SOURCE
rpool/export/depot/solaris referenced 6.07G -
rpool/export/depot/solaris compressratio 1.15x -
# pkgrepo rebuild -s /export/depot/solaris
Initiating repository rebuild.
Up to this point the task is finished.
But for good practice and also for later incremental updates, snapshot it:
# zfs snapshot rpool/export/depot/solaris@release
NOTE
$ zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
depot 149G 38.1G 111G 25% 1.00x ONLINE -
export 464G 339G 125G 73% 1.00x ONLINE -
rpool 55.5G 14.4G 41.1G 25% 1.00x ONLINE -
Let me show a basic scheme that's been useful for years:
# zfs list -o name,mountpoint -t all -r depot | grep -v bk
NAME MOUNTPOINT
depot /depot
depot/software /depot/software
depot/solaris /depot/solaris
depot/solaris/11.2 /depot/solaris/11.2
depot/solaris/11.2@release -
depot/solaris/11.3 /depot/solaris/11.3
depot/solaris/11.3@release -
depot/studio /depot/studio
depot/studio/12 /depot/studio/12
depot/studio/12@release -
# ll /depot/solaris/ /depot/studio/
/depot/solaris/:
total 9
drwxr-xr-x 3 root root ... 11.2
drwxr-xr-x 3 root root ... 11.3
lrwxrwxrwx 1 root root ... current -> 11.3
/depot/studio/:
total 5
drwxr-xr-x 3 root root ... 12
lrwxrwxrwx 1 root root ... current -> 12
But once this is done establishing access to it is covered on a separate post.
In addition, after these previous tasks are complete, it may be necessary to update it.
For instance, the best way to install Oracle Solaris Studio is to set up a local IPS repository.
The procedure is reasonably well and fairly documented, but let's review it anyway.
What may not be very clear is that by default a local repository would be assumed to rest in /var/pkg/repo, even though it doesn't exist by default. This means that a dedicated ZFS dataset could or should have its mountpoint property set to this default, although it could be better to use symbolic links yielding something similar to /var/pkg/solaris/11.x/release and /var/pkg/solaris/11.x/sru-# and so on... But below, as dealing with Studio packages instead of OS packages, I've followed the crowd and created something completely apart. Anyway, note that in addition to compression (compression=on), access time could be turned off (atime=off) to buy some performance:
# zfs create rpool/export/depot
# zfs create -o compression=on rpool/export/depot/studio
NAME PROPERTY VALUE SOURCE
rpool/export/depot compression off default
rpool/export/depot/studio compression on local
# pkgrepo create /export/depot/studio
# ll /export/depot/studio
...
-rw-r--r-- 1 root root 78 Nov 6 10:45 pkg5.repository
I'll use the support version of the repository which requires an Oracle support plan.
With no support plan the release version can be used according to terms and conditions.
For both versions it's necessary to get certificate(s) at https://pkg-register.oracle.com:
# cd /var/pkg/ssl
# ll Studio_Support.*
...
-rw------- 1 root root 753 ... Studio_Support.cert.pem
-rw------- 1 root root 887 ... Studio_Support.key.pem
I'll use an script to populate and later update the local repository. If behind a proxy, set http_proxy and https_proxy accordingly. But sometimes a proxy/firewall can block the several TCP connections from the remote port 443 to random ports and the symptoms are stalls or ugly messages. In case of difficulties check your command line, your certificates and then the proxy/firewall settings. Perhaps you may need to temporary alter your wired connection and temporarily bypass something.
# cat update-studio
#!/bin/sh -
SSL=/var/pkg/ssl
PRODUCT=Studio_Support
PRODUCT=Studio_Support
KEY=$SSL/$PRODUCT.key.pem
CERT=$SSL/$PRODUCT.cert.pem
SOURCE=https://pkg.oracle.com/solarisstudio/support/
TARGET=/export/depot/studio
pkgrecv -s $SOURCE -d $TARGET --key $KEY --cert $CERT '*'
[ $? -eq 0 ] && pkgrepo refresh -s $TARGET pkgrecv -s $SOURCE -d $TARGET --key $KEY --cert $CERT '*'
But IPS repositories are not only useful for Solaris Studio.
In fact, it's crucial for Solaris 11 itself.
Start with just the initial release version of the repository.
Later, it can turn into a multiple support release updates repository.
The big picture is rather simple:
- Create a dedicated file system;
- Obtain just the release packages.
For obtaining the release packages, two methods are available.
As always, begin by creating a dedicated ZFS file system.
Ideally, set compression and atime properties as already described.
# zfs create rpool/export/depot/solaris
The release packages can be found at http://pkg.oracle.com/solaris/release.
Alternatively, download and concatenate a split ISO file.
I'm not sure which is the most efficient.
I do know that burning the ISO file, instead of lofs-mounting it is bad idea.
It'll take much longer to receive all the packages.
Underlying seek in optical media isn't efficient.
The manifests processing is specially awful.
Getting the release packages.
Choose one of the following options.
OPTION 1:
# pkgrepo create /export/depot/solaris
# URI=http://pkg.oracle.com/solaris/release
# URI=http://pkg.oracle.com/solaris/release
# pkgrecv -s $URI -d /export/depot/solaris '*'
# pkgrepo refresh -s /export/depot/solaris
Processing packages for publisher solaris ...
Retrieving and evaluating 4401 package(s)...
Download Manifests ( 369/4401) -
... Retrieving and evaluating 4401 package(s)...
Download Manifests ( 369/4401) -
OPTION 2:
# lofiadm -a /export/archive/sol-11_1-repo-full.iso
/dev/lofi/1
/dev/lofi/1
# mount -F hsfs /dev/lofi/1 /mnt
# ll /mnt
total 29
drwxr-xr-x 3 root root 2.0K ... repo
-rwxr-xr-x 1 root root 1.3K ... NOTICES
-rw-r--r-- 1 root root 3.2K ... COPYRIGHT
-rw-r--r-- 1 root root 7.4K ... README
(on an Intel Core 2 Quad Q6600 2.40 GHz with slow single disk)
total 29
drwxr-xr-x 3 root root 2.0K ... repo
-rwxr-xr-x 1 root root 1.3K ... NOTICES
-rw-r--r-- 1 root root 3.2K ... COPYRIGHT
-rw-r--r-- 1 root root 7.4K ... README
(on an Intel Core 2 Quad Q6600 2.40 GHz with slow single disk)
# time rsync -q -aP /mnt/repo/ /export/depot/solaris
real 8m23.000suser 1m20.248s
sys 3m43.634s
NOTE
Under VirtualBox that could be ridiculously more time consuming:
real 173m51.306s
user 1m19.884s
sys 3m14.512s
# umount /mnt
# lofiadm -d /dev/lofi/1
# zfs get referenced,compressratio rpool/export/depot/solaris
NAME PROPERTY VALUE SOURCE
rpool/export/depot/solaris referenced 6.07G -
rpool/export/depot/solaris compressratio 1.15x -
# pkgrepo rebuild -s /export/depot/solaris
Initiating repository rebuild.
Up to this point the task is finished.
But for good practice and also for later incremental updates, snapshot it:
# zfs snapshot rpool/export/depot/solaris@release
NOTE
On this post I've been using rpool/export/depot.
In fact what I prefer is to create dedicated pools.
That is, one for export and other for depot.
$ zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
depot 149G 38.1G 111G 25% 1.00x ONLINE -
export 464G 339G 125G 73% 1.00x ONLINE -
rpool 55.5G 14.4G 41.1G 25% 1.00x ONLINE -
Let me show a basic scheme that's been useful for years:
# zfs list -o name,mountpoint -t all -r depot | grep -v bk
NAME MOUNTPOINT
depot /depot
depot/software /depot/software
depot/solaris /depot/solaris
depot/solaris/11.2 /depot/solaris/11.2
depot/solaris/11.2@release -
depot/solaris/11.3 /depot/solaris/11.3
depot/solaris/11.3@release -
depot/studio /depot/studio
depot/studio/12 /depot/studio/12
depot/studio/12@release -
# ll /depot/solaris/ /depot/studio/
/depot/solaris/:
total 9
drwxr-xr-x 3 root root ... 11.2
drwxr-xr-x 3 root root ... 11.3
lrwxrwxrwx 1 root root ... current -> 11.3
/depot/studio/:
total 5
drwxr-xr-x 3 root root ... 12
lrwxrwxrwx 1 root root ... current -> 12
Monday, November 5, 2012
C++ remote build host setup
It's not that difficult to setup the a remote build host.
The problem is that it's not fully and/or clearly described in documentation.
In addition, there's a small caveat or trick to get it working: Internal Updates.
For the general setup, Oracle has pointed me out to the following good references:
To begin, install Oracle Solaris Studio on every local coding and remote build hosts.
On the coding nodes, hosts with a GUI, update all plug-ins, notably the C/C++ one.
This will assure the correct configuration and operation of remote build hosts.
You should see something similar to the following:
To finish preparations, also make sure that:
The remote build configuration is set up in the Build Hosts Manage dialog box.
It's invoked by the main menu File | Create Remote C/C++ Project | Manage Hosts...
To change a remote build host properties,
click the Properties... button.
To add a remote build host,
click the Add.. button:
The problem is that it's not fully and/or clearly described in documentation.
In addition, there's a small caveat or trick to get it working: Internal Updates.
For the general setup, Oracle has pointed me out to the following good references:
To begin, install Oracle Solaris Studio on every local coding and remote build hosts.
On the coding nodes, hosts with a GUI, update all plug-ins, notably the C/C++ one.
This will assure the correct configuration and operation of remote build hosts.
You should see something similar to the following:
 | |
| C/C++ plug-in updates (Internal Updates) |
To finish preparations, also make sure that:
- The same login account is consistently used.
This includes uid and gid values as well.
- SSH (preferably) or NFS is properly configured.
Note that NFS is important to the mixed mode only.
The remote build configuration is set up in the Build Hosts Manage dialog box.
It's invoked by the main menu File | Create Remote C/C++ Project | Manage Hosts...
To change a remote build host properties,
click the Properties... button.
To add a remote build host,
click the Add.. button:
- Type in the host FQDN in Hostname and click the Next > button.
Then enter the Login/User and Password information.
Consider ticking Remember Password checkbox.
Click the OK button.
- After a while the Tool Collections should be correctly detected.
Select the appropriate project files access (synchronization) method.
Again, this depends on the desired remote development mode.
Finally, click the Finish button to conclude the host addition.
- There's an additional step if the synchronization is System Level File Sharing.
Use the Path Mapper... button to map paths to the sources' central location.
C++ remote build host
This is one of the coolest features present in Oracle Solaris Studio 12.3 and NetBeans 6.9.
The term Remote Development seems usual, but I prefer the clearer Remote Build Host.
In a remote building scenario two separate hosts have the following activities (roles):
The remote building also supports running and debugging on mixed platforms.
Of course, this implies portable C/C++ coding.
For the sake of sanity I'll stick to, Solaris!
Depending on the setup, where the C/C++source files are kept, 3 modes are supported:
The term Remote Development seems usual, but I prefer the clearer Remote Build Host.
In a remote building scenario two separate hosts have the following activities (roles):
- Coding : A desktop or a laptop with a full-blown GUI IDE.
- Building : A very powerful and efficient server with no GUI.
The remote building also supports running and debugging on mixed platforms.
Of course, this implies portable C/C++ coding.
For the sake of sanity I'll stick to, Solaris!
Depending on the setup, where the C/C++source files are kept, 3 modes are supported:
- Simple : At the local coding host.
- Mixed : On shared storage, such as NFS.
- Full : On the remote build host.
Thursday, November 1, 2012
C++ stability & evolution
I love the C++ language since the beginning.
For me it all begins with BASIC, then Pascal, then C, then Object Pascal and finally C++.
On this blog I intend to share my experience with Oracle Solaris Studio 12.3.
I do not intend to write about C++, at least not on this blog.
What all this had to do with Solaris after all?
Well, C has everything to do with UNIX™ and Solaris is UNIX™ for the best.
I've never looked at any Solaris source code but for the most part it must be purely C.
At the same time a lot of C++ code should out there, despite Java.
Solaris is recognized by its ABI stability, a practical and important aspect to business.
This ABI stability may represent a key foundation and that's why it may be a critical factor.
See Stephen Clamage's Stability of the C++ ABI: Evolution of a Programming Language.
Nevertheless, a new C++ standard has finally emerged, know as C++11.
The language's author, Bjarne Stroustrup, still like the former designation, C++0x.
The new standard, ISO/IEC 14882:2011, is at ISO and a draft is available for free.
As projected there are modifications that may affect ABI implementations.
Bjarne's C++11 FAQ is a must reading for everyone using the old C++03 standard.
Current compilers, such as Oracle Solaris Studio 12.3, fully support only the old standard.
For me it seems inevitable that in the next couple of years things will have to change.
But I don't believe Solaris will break its 20 yeares ABI backwards compatibility.
I do hope that this major breakthrough is carefully handled.
For me it all begins with BASIC, then Pascal, then C, then Object Pascal and finally C++.
On this blog I intend to share my experience with Oracle Solaris Studio 12.3.
I do not intend to write about C++, at least not on this blog.
What all this had to do with Solaris after all?
Well, C has everything to do with UNIX™ and Solaris is UNIX™ for the best.
I've never looked at any Solaris source code but for the most part it must be purely C.
At the same time a lot of C++ code should out there, despite Java.
Solaris is recognized by its ABI stability, a practical and important aspect to business.
This ABI stability may represent a key foundation and that's why it may be a critical factor.
See Stephen Clamage's Stability of the C++ ABI: Evolution of a Programming Language.
Nevertheless, a new C++ standard has finally emerged, know as C++11.
The language's author, Bjarne Stroustrup, still like the former designation, C++0x.
The new standard, ISO/IEC 14882:2011, is at ISO and a draft is available for free.
As projected there are modifications that may affect ABI implementations.
Bjarne's C++11 FAQ is a must reading for everyone using the old C++03 standard.
Current compilers, such as Oracle Solaris Studio 12.3, fully support only the old standard.
For me it seems inevitable that in the next couple of years things will have to change.
But I don't believe Solaris will break its 20 yeares ABI backwards compatibility.
I do hope that this major breakthrough is carefully handled.
Subscribe to:
Posts (Atom)