|
|
Last update:
Mon Oct 3 16:47:36 2005
Wed Oct 5 18:49:21 2005
Sat Oct 14 17:17:33 2006
Thu Mar 29 06:18:56 2007
Mon Mar 9 14:51:46 2009
Our facility is more than 25 years old, and has a
huge amount of installed software. Depending on
the platform, the default system search path on
our systems contains between 2000 and 13,000
programs, which you can readily test on any of
them with this simple command:
pathfind -a PATH "*" | wc -l
In addition to Unix-vendor-provided software, our systems have all of the important GNU utilities from the Free Software Foundation, the Portland Group and Intel compilers (Fortran 77/90/95, C, C++) for IA-32, IA-64, and AMD64, the PathScale compilers (Fortran 77/90/95, C, C++) for AMD64, the Princeton/AT&T lcc C compiler, the NAG Fortran 90/95 compilers, and on some systems, the commercial Matlab, Maple, Mathematica, SAS, and S-Plus systems for numerical and symbolic mathematics, and statistics. We also have the NAG and GNU GSL scientific libraries that can be used from Fortran and C programs. Further information about these, and many more, packages can be found at our software Web site: http://www.math.utah.edu/software/.
Where are software source distributions stored?
There are five main directory trees for software source archives:
| Directory tree | Contents |
| /usr/local/src | public non-GNU freeware |
| /usr/local/sys/src | commercial licensed software |
| /usr/local/gnu/src | GNU freeware |
| /usr/local/math | mathematical freeware |
| /u/ftp/pub/ | freeware packages in our FTP tree |
Each of these has subdirectories named by software package. For the first two, each subdirectory generally contains a WHERE-FROM file that records the origin elsewhere on the Internet of the package. The GNU packages generally come from the same source ftp://ftp.gnu.org/gnu/, but some also have WHERE-FROM files to record developer sites that sometimes have newer versions than the official GNU ones.
Within each package directory are distribution files, typically with names ending in .tar.gz or .tar.bz, indicating Unix tar archives compressed with gzip or bzip2. There may also be README.* files that record build problems.
Each package directory contains a logs subdirectory, in which subdirectories named by particular package versions contain build logs. Many of them are generated by the automated software-build system, build-all, described in Chapter 8 of the book Classic Shell Scripting.
What packages can I copy to my personal computer?
You are welcome to copy anything from the three freeware directories listed above. Under no circumstances may the commercial distributions be copied to other systems. If in doubt, please ask our systems staff.
Whenever you copy a software distribution from these directories, or any other Internet sites, please check for accompanying detached digital-signature files with extension .asc or .sig. Copy those files as well, and then verify the digital signatures before attempting to build software.
By doing so, you can avoid nasty surprises if the software package has been maliciously modified by an attacker, something that has already happened to major software distribution sites.
A tutorial on digital signatures is available here.
How do I run Unix programs on my Microsoft Windows computer?
There are several ways to do this:
More information on this topic is available here.
How do I run Microsoft Windows applications on my Unix system?
Fewer alternatives are available than for the reverse environment, but you might find a workable solution by following this link.
I use program x on Microsoft Windows. What is its analogue on Unix?
Some software packages run in both Microsoft Windows and Unix environments under the same, or similar, names. In general, however, one needs a Rosetta Stone to translate from one package name to another. One such source is a Web page that lists Linux software equivalent to Windows software.
Where are binary programs, header files, and load libraries installed?
Following widespread and long-standing Unix practice, and also GNU conventions, software installations for free packages are done with a path prefix of /usr/local, so binary programs are installed in /usr/local/bin, C/C++ header files in /usr/local/include, and load libraries in /usr/local/lib.
Some platforms support two or more memory models and/or load library formats, so to distinguish between identically-named libraries, they must be stored in different directories. In the following table, the default library directories are highlighted:
| Vendor/CPU and O/S | 32-bit libraries | 64-bit libraries |
| Apple PowerPC Mac OS X | /usr/local/lib | /usr/local/lib64 |
| AMD64 GNU/Linux | /usr/local/lib | /usr/local/lib64 |
| HP/Compaq/DEC Alpha OSF/1 | /usr/local/lib32 | /usr/local/lib |
| IA-64 GNU/Linux | /usr/local/lib32 | /usr/local/lib |
| SGI MIPS IRIX | /usr/local/lib, /usr/local/lib32 | /usr/local/lib64 |
| Sun SPARC Solaris | /usr/local/lib | /usr/local/lib64, /usr/local/lib/64 |
To link C and Fortran programs with one of these libraries, use something like this:
% cc -I/usr/local/include myprog.c -o myprog -L/usr/local/lib -lgsl % f77 myprog.f -o myprog -L/usr/local/lib -llapack
The compilers and linkers on some operating systems, and the GNU compilers, automatically search /usr/local/include for header files and /usr/local/lib for libraries, so you may not require the -Ipath and -Lpath options.
With shared libraries, it is usually desirable to record in the executable program where the libraries were found at link time, to avoid the need to set the LD_LIBRARY_PATH environment variable at run time. Regrettably, practices differ across Unix systems, but commands like one of these should work, after adjusting the library pathname appropriately:
% cc -I/usr/local/include myprog.c -o myprog -L/usr/local/lib -lgmp -Wl,-rpath,/usr/local/lib % cc -I/usr/local/include myprog.c -o myprog -L/usr/local/lib -lgmp -R/usr/local/lib
There are often multiple versions of installed libraries, and those in the /usr/local tree are almost always the newest. Use the ldd command, available on most systems, to find which libraries are used. Here is an example from a Sun Solaris SPARC system:
% ldd /usr/local/bin/ndiff
libgmp.so.3 => /usr/local/lib/libgmp.so.3
libCrun.so.1 => /usr/lib/libCrun.so.1
libm.so.1 => /usr/lib/libm.so.1
libw.so.1 => /usr/lib/libw.so.1
libc.so.1 => /usr/lib/libc.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
Where are programs and library software documented?
Unix manual pages, accessed with the man command, are the most common, and briefest, form of software documentation:
% man -a sqrt
The -a option ensures that all manual pages of the given topic name are displayed, since there may be more than one.
Manual pages are traditionally divided into several sections: 1 for commands, 2 for system calls, 3 for library calls, and so on, corresponding to subdirectories man1, man2, man3, .... You can request the manual page from a specific section like this:
% man -s 3m sqrt
Many of the manual-page files are also available in HTML form, and can be visited by browsers at the local URL file:///usr/local/man/html/ . These files are not visible from Web browsers on remote computers.
Typeset versions of some manual-page files, suitable for printing and viewing, are available in PDF (Portable Document Format) and PostScript form, at file:///usr/local/man/ps/ and file:///usr/local/man/pdf/ .
The locally-written man2ps program can be used to generate typeset manual pages in PostScript:
% man2ps /usr/local/man/man1/gcc.1 > /tmp/gcc.ps
You can convert PostScript to PDF with at least four different programs, as shown by these examples:
% distill /tmp/gcc.ps % pstill /tmp/gcc.ps % ps2pdf /tmp/gcc.ps % convert /tmp/gcc.ps /tmp/gcc.pdf
In each case, the output PDF file is /tmp/gcc.pdf.
Most GNU software, and many other packages that we have developed or installed, are documented in the emacs info system. You can access it inside the editor by typing C-h i, and externally, with the standalone info and xinfo programs. The info system is an easy-to-use hypertext system that predates HTML and the World-Wide Web by 15 years. Once inside, type ? for brief help, h for a tutorial, and d to return to the top-level directory. Type q to quit.
In emacs, a subsequent entry to the info system puts you back where you last left it, so often, no further navigation is needed. Also, your navigation history is preserved, as long as you do not exit the editor.
The info system provides detailed documentation, and for many programs and packages, their info nodes are on-line indexed books that, if printed, would be hundreds of pages long.
Other locations where you can find on-line documentation include the /usr/local/doc tree, and for classroom software, the /u/cl/doc tree. For example, under the first of these, the c, cs, f77, fortran, and pascal directories contain online books and drafts of international standards for the C, C++, C#, Fortran, and Pascal programming languages.
Commercial and other software usually has its own documentation, described in the frequently-asked questions (FAQ) pages for Maple, Maxima, Mathematica, Matlab and Octave, MuPAD, SAS, S-Plus and R, TeX and Metafont, and others listed in the top-level computing facilities FAQ directory.