If you build a program with one version of Studio (like 11 or 12.x), you cannot expect to link to libraries from earlier Studio versions. You don't say what programming language you are using, but the issue is most common with Fortran and C++.
For example, unless you take steps to do avoid the problem (see below), C++ programs using the STLport or Interval libraries will try to link at run time to shared libraries installed with the compiler. If the program was built with Studio 11 or 12.x, linking with the Studio 10 libraries will not work well.
However, if the program links only to the default runtime libraries in /usr/lib, whether Studio is installed on the target system, or which version is installed, does not matter. You can find out whether this is the case by running "ldd" on your program on the system where you built it:
% ldd myprog
The output will show all shared libraries the program uses, and where they come from. If none of the libraries are in the compiler installation area, you don't have a problem.
The only other issue is Solaris compatibility. If you build a program on Solaris version N, you can expect to run the program on Solaris N+1 or later, but not on Solaris N-1 or earlier. The reason is that Solaris preserves old interfaces, but adds new ones. A program might depend on a Solaris interface not present in an older Solaris version. For Solaris 10 in particular, later updates introduced new features and interfaces not in earlier updates. For example, if you build a program on update 10, it might not run on an original Solaris 10.
In addition, if the build system has been patched with a later version of the C++ runtime libraries (package SUNWlibC), the target system should have the same or a later patch. You can find out the patch version by running the command
% showrev -p | grep SUNWlibC
Going back to my original discussion of libraries that come with Studio, this paper
http://www.oracle.com/technetwork/articles/servers-storage-dev/linkinglibraries-396782.html
describes best practices in building programs for distribution so that they don't depend on the compiler installation.
Steve Clamage
Oracle C++ Compiler Team