PNCE-Unix Research Resources

PNCE-Unix Environment Documentation

Recommended Binary (bin) Directory Structure

The PNCE-Unix/Glue environment is designed as a heterogenous environment, meaning that it supports a number of different operating systems and platforms. At this time, it supports Solaris on sparc architecture, and Linux on 32 bit and 64 bit (both amd and intel) architectures. Other platforms had been supported in the past, and more will likely be supported in the future.

Creating a homogeneous user environment across a heterogeneous cluster is not a trivial task, but the Glue system has been quite successful in this regard. A difficulty with multi-platform clusters is ensuring the right executable is run on the machine you are using, without the user having to explicitly specify the system he is running on. This becomes increasing important with batch jobs running under some sort of batch processing and scheduling facility which may farm a job off to any of a number of systems without the user knowing ahead of time where the job will run. Although such facilities allow you to limit the code to certain platforms, allowing your code to run on multiple platforms will likely increase the available CPU time for your jobs.

This page describes our recommended structure for binary directories. It is somewhat more complicated than the simple ~/bin directory that suffices on homogeneous platforms, but it can transparently handle the task of running the right binary for your platform, and it is not that difficult once you get used to it. This structure, or closely related variants, is used by the systems staff and is strongly recommended for use in the binary directories for users, groups, and projects. Indeed, it is recommended that you start using this structure now, even if you are not planning to run on multiple platforms yet or do not care to take advantage of 64 bit processing available on some linux platforms, to save aggravation when you wish to do so.

The system makes use of the automatic expansion of AFS of the term @sys into a string describing the operating system of the machine you are on. The following example shows how it would be used in a person's home directory to handle shell scripts and binaries for Sun Solaris and Red Hat Linux systems. It can easily be modified for other locations and other platforms.

1. Create directories for the different platforms you wish to support: e.g.
   
mkdir ~/bin
mkdir ~/bin/.sun4x_59
mkdir ~/bin/.i386_rel30
   The names sun4x_59 and i386_rel30 are the sysnames for the platform, in these cases a Solaris 9 system running on the Sparc architecture and a Red Hat Enterprise Linux v3.0 system running on an x86 system. These are discussed in more detail further on. The leading period in the directory name prevents it from showing up in ls unless the -a or -A option is given (you can omit it if you prefer to see the platform specific directories. You can also place these directories elsewhere if desired).
2. If you have platform independent scripts or executables, you can place these directly in your ~/bin directory, just as you would on a homogeneous cluster.
3. If you have a program which can be compiled for either platform, compile it on the linux platform and stick the executable in the ~/bin/.i386_rel30 directory, and then repeat the compilation for the sun and put the executable in the ~/bin/.sun4x_58 directory. Keep the same name for the executable in both platform specific subdirectories.
4. So far we have not gained much. But now cd to the bin directory, and make the symbolic link
   
cd ~/bin
ln -s .@sys/EXECUTABLE .
   where EXECUTABLE is the name of the executable from the previous step. Now, assuming that ~/bin is in your path, when you type EXECUTABLE at the shell prompt, it will translate to ~/bin/EXECUTABLE which in turn, because of the symbolic link, become ~/bin/.@sys/EXECUTABLE and then AFS will magically expand the @sys part to the sysname for the platform you are currently running on, meaning that you should get the correct executable.

You can make variations on the above if you prefer to see the system directories or prefer a different structure. Another common structure is to have platform specific directories outside of bin, with source and bin directories beneath that, and symbolically link from your main bin directory to these.

Managing compilations for multiple platforms

In the above example, we mentioned that you need to compile the code on each system you wish to run on. Some software packages allow you to create a platform specific directory (we recommend using the sysname) underneath the main source directory, then cd to that directory, and the configure and make commands are smart enough to find the source code, and will put all the platform specific file in this subdirectory. You can then have multiple build directories, one for each platform.

Not all software packages support this. And in particular, if it is code you wrote, it likely will not be if you are reading this page. For simple programs, you can do something similar to the above with symbolic links. Assume you have an application with two header (.h) and two C code (.c) files and a Makefile. Make a platform specific subdirectory as above, cd to it, then make symbolic links to the five application files. Then run make as normal; the code will build in your subdirectory using the source files in the directory above.

The symbolic link technique can be extended with good success to much more complicated applications, but it starts to get difficult to set up the platform specific subdirectories, since you have to replicate any directory structure beneath the main source directory and recursively link and regular files. PCS has a script /dept/phys/software/misctools/make_build_dir.pl which will replicate a source tree for you. Just go the root of the source tree for your application, and run the script. Without any arguments, it will give a help message, then prompt if you wish to continue with the default values (which are typically correct). It will generate a build subdirectory, with a further subdirectory for your platform type, then recursively link regular files and create subdirectories as needed. (The code puts all build directories underneath build rather than directly beneath the source root to avoid issues with linking other build directories as well as the source tree.)

Sysnames

We mentioned previously the sysnames for some platforms. In general, a sysname provides information about the hardware architecture (e.g. Sparc, x86, etc) and the OS (e.g. Solaris, Linux, and the version). You can find out the sysname for the system you are on with the command

Some common sysnames in the PNCE-Unix/Glue cluster are: