InformIT: Mac OS X Unleashed > Installing Software at the Command Line

Table of Contents

Installing Software at the Command Line

The majority of the Unix software you'll find that hasn't been specifically made for OS X is created by other users just like you. Because of the wide range of individuals involved, the possibilities for how it might be delivered and what you will need to do to install it are truly limitless. We'll do our best to give an overview of the techniques used, but you should pay attention to the author's instructions to see whether or where they differ from our suggestions. Also, don't be afraid to use your own common sense if you find something that doesn't have instructions and our samples don't appear to apply.

Regardless of the actual steps involved in the installation, there are some things to keep in mind if you want to keep your system in some semblance of order.

You'll usually have as much flexibility about where you install software in Unix as in Mac OS. Unfortunately, although Mac OS invisibly and automatically updates the database of software that's installed for you, Unix doesn't. If you install software in random places throughout the system, you will need to continuously update your PATH variable to reflect the changes. For this reason, despite having the option to install just about anywhere, there are a few common and highly recommended locations where you'll probably be happiest if you confine your installs. Specifically, those locations are the /usr/local and /opt directory trees. They are the most common and best places to install software if you want convenience in your system.
If you have multiple users on the system, even if you update your own PATH, other users' paths won't be updated, and, consequently, they might not be able to run the software. This can be an advantage, or disadvantage, depending on whether you want to hide the software from others or make it publicly available.
If you decide to reconfigure your system or reinstall something, it will be much easier if you keep a complete copy of the distribution and any special options you picked to make it work. Use the tar command and compress or gzip commands (explained in Chapter 13, "Common Unix Shell Commands: File Operations"), after you've successfully managed to install it. You'll probably want to make clean the distribution first, if possible—that incantation will be explained shortly.
If you want to maintain your sanity, it will help if you always download software packages into the same location, and do all your configuration and software building in the same directory.
Never compile or install software as the root user. Some would suggest that we append unless absolutely necessary to that dictum, but we won't. Some software might require that you install it as root, but the root user is the single user with the capacity to destroy your system with a single command. It might be preachy to suggest that you're probably better off without any software that requires you to be root to install it, but until you know when it's safe to ignore this suggestion, you'll be much safer following it.
Another useful trick for keeping your system in order is to create a special user ID that is used solely for software installations and management. The ownership of the /usr/local and /opt directories can be set to this user ID, as well as the ownership of wherever you download software and where you store it. This user ID does not need to have, and should not have, administrator privileges on the system. This minimizes both the risk of simply doing something wrong, and accidentally damaging the running system. It also minimizes the impact that a malicious user, distributing damaging scripts in the guise of useful software, can do to your system.

Downloading

You'll find Unix software being distributed in Usenet newsgroups, on Web pages, FTP servers, through e-mail, and other mechanisms. No matter how it's distributed, you are going to need to transfer a copy of the software, from wherever it is stored, onto your local machine.

You've got all the tools necessary to accomplish any of these in both the command-line programs discussed here and in the previous chapter, as well as the GUI clients covered earlier.

Keep in mind while acquiring the software that things will go smoothest if

It is downloaded by the user who will be responsible for the installation.
It is downloaded into a directory where it can be unpackaged and compiled, if necessary. This includes the requirement for sufficient disk space, as well as the appropriate permissions for the user ID that will be doing the installation.
If you're using ftp, use binary mode.

Unarchiving

Some software will come as source code (the language that compilers read) and that explains to the compiler how to create a finished program. Some will come as final executable programs. Either way, most will come as a tarfile compressed with either the compress program (usually denoted by a .Z file suffix), or the gzip program (usually denoted by a .gz suffix).

The first thing you'll need to do after downloading, therefore, is usually to uncompress or gunzip the tarfile.

Next you'll usually need to untar the tarfile (with tar -xvf <tarfile> ). Before you do that, however, it's usually a good idea to make sure what's in the tarfile. You're interested in the contents, as well as where the tarfile wants to put the stuff that's in it. The second item is of particular importance—some software authors have the sloppy habit of letting their tarfiles place files in the current directory rather than a subdirectory (as mentioned in the section on tar in Chapter 13). Additionally, some packages are distributed as tarfiles that are designed to untar in place in the system. That is, they place files directly into their final locations (such as /usr/local/bin), rather than into a temporary subdirectory for subsequent installation.

Finally, keep in mind that if you download with a Web browser, it isn't unusual for the browser to remove the file suffix without actually doing anything to the file. This results in downloaded gzip files that are missing their .gz suffix. If you have downloaded a piece of software with a Web browser that arrives as a .tar file but tar refuses to unpack it, try adding a .Z or .gz suffix and see whether uncompress or gunzip will process the renamed file.

If you've downloaded a precompiled application that only needs you to unpack it in place, or for you to put it in a final location after unpacking the distribution, you're all set. If you've downloaded a package that is distributed as source code, then skip to the next section on compiling software.

Installing `lynx`

The lynx command-line Web browser is such a useful tool that we'll do a download and unarchive install right now. A precompiled version of lynx is available from http://www.osxfaq.com/downloads/.

Before you install lynx, we recommend that you make a change in your system's configuration that will help keep your system safe from malicious software and accidents during software installs. If you didn't create the unprivileged software user with group tire that we recommended in Chapter 11, "Additional System Components," go back and create that user now. Next, su to the root user. Finally, change the ownership of the directory /usr/local/ on your machine to belong to the software user and group. From the command line, this looks like

 [localhost:~nermal] ray% su
Password:
[localhost:/Users/nermal] root# cd /usr
[localhost:/usr] root# chown software.tire /usr/local
[localhost:/usr] root# ls -ld local
drwxr-xr-x  4 software  tire  92 Apr 21 22:00 local

Now, log out and log back in as the unprivileged software user that you created earlier.
Start a terminal and create the directories /usr/local/lib and /usr/local/bin (mkdir /usr/local/lib; mkdir /usr/local/bin).
Next, point your browser at http://www.osxfaq.com/downloads/ and download the files lynx.gz and lynx.cfg.

Chances are if you're using Internet Explorer, its going to insist on decompressing lynx.gz automatically. If not, you will need to find the file (double-click lynx.gz in the download manager, and hit reveal in finder), and then drag it to your software user's Documents folder.

In the terminal, cd ~/Documents. Uncompress the lynx.gz archive with the command gunzip lynx.gz. If your browser already did this for you, a file named lynx might be in your Desktop folder.
Wherever the file lynx ends up, copy it to /usr/local/bin/. Use cp < path to lynx > /usr/local/bin/. < path to lynx > might just be lynx, or it might be ~/Desktop/lynx.
Read the beginning of lynx.cfg. You can do this with less lynx.cfg. You can set a lot of configuration defaults in this file, but for now, leave the defaults as they are and copy the file to its intended destination. It should tell you that it belongs in /usr/local/lib/lynx.cfg, so cp < path to lynx.cfg > /usr/local/lib/lynx.cfg.
Just to make sure that the lynx file is executable, chmod 755 /usr/local/bin/lynx.
Log out and back in as your normal user. You might need to set your path to include /usr/local/bin, if it doesn't already. The easiest way to do this, as explained in Chapter 12, "Introducing the BSD Subsystem," is to extend your path with set path=($path /usr/local/bin) placed in your .cshrc file.

The lynx application should now be executable and behave just as detailed in Chapter 15, "Command-Line Applications and Application Suites."

Compiling

Compilation is the process that a program-language compiler uses to take source code and convert it into an actual executable application. It is also used to describe running the compiler to perform the compilation. The idea of having to cook your own software from the raw ingredients probably evokes images of impossibly cryptic commands and more headaches than you would ever want to deal with to those coming from a Macintosh or Windows background. Thankfully, compiling prepackaged source code isn't quite cooking from the raw ingredients—it's usually more like warming up a TV dinner. (If you're interested in learning to cook software from scratch, we recommend Kernigan and Ritchie's excellent The C Programming Language, and Donald Knuth's The Art of Computer Programming books on software architecture.

It's still complicated enough—and there are plenty of places it can go wrong—that most users will at least initially find it less than fun. It'll be the last scary topic we introduce in this book though—everything after this is applications of what you've learned in the last few chapters and this one, and the introduction of new programs for you to use. In actuality, this stuff isn't that scary either—if you make it through this chapter and we haven't scared you away from the BSD subsystem, you're home free—we promise!

Basic Steps: `configure, make`

Let's start with an example of a software install—things can get more complicated than this, but for many applications that have been written by conscientious programmers these steps will suffice. We'll assume that the software package pine4.33 has been successfully downloaded, uncompressed, and untarred. Installs shown here are also done assuming you're logged in as your software user, and that you've downloaded software into the Documents directory.

Almost universally, the first command you'll issue to compile software is either ./configure (if it's present) or make (if ./configure is not present). For pine, the only things you have to type are

make
build osx
cp bin/pine /usr/local/bin/
mkdir /usr/local/man/
mkdir /usr/local/man1/
cp docs/pine.1 /usr/local/man/man1/

That doesn't look too hard, does it? The basic operations are simply make, build, and copying some files into standard locations in the file system.

If you'd like to try this example, the pine package shown here can be downloaded from ftp://ftp.cac.washington.edu/pine/pine4.33.tar.gz. The simplest way to do this is with lynx, by issuing the following:

cd ~/Documents
lynx -dump ftp://ftp.cac.washington.edu/pine/pine4.33.tar.gz > pine4.33.tar.gz
gunzip pine4.33.tar.gz
tar-xf pine4.33.tar
[localhost:~/Documents] software% cd pine4.33/

[localhost:~/Documents/pine4.33] software% ls

     CPYRIGHT  README build  build.cmd contrib
     doc   imap   makefile  pico  pine

There's no file named configure, so try make.

[localhost:~/Documents/pine4.33] software% make

     Use the "build" command (shell script) to make Pine.
     You can say "build help" for details on how it works.

So, this software install isn't quite standard—it doesn't use make, other than to tell us that it doesn't use make. If you read the README, and look at the output of build help, you'll observe that there's an osx option already available, so give that a try:

[localhost:~/Documents/pine4.33] software% ./build osx

     make args are CC=cc

     Making c-client library, mtest and imapd
     make CC=cc osx
     Applying an process to sources...
     tools/an "ln -s" src/c-client c-client
     .
     ...much output deleted...
     .
     Building c-client for osx...
     echo GSSDIR=/usr/local  > c-client/SPECIALS
     cd c-client;make osx EXTRACFLAGS=''      EXTRALDFLAGS=''     .
     .
     .
     Once-only environment setup...
     echo cc > CCTYPE
     echo -g -O '' > CFLAGS
     echo -DCREATEPROTO=unixproto -DEMPTYPROTO=unixproto      .
     .
     .
     ln -s os_osx.h osdep.h
     ln -s os_osx.c osdepbas.c
     ln -s log_std.c osdeplog.c
     .
     .
     .
     `cat CCTYPE` -c `cat CFLAGS` mail.c
     `cat CCTYPE` -c `cat CFLAGS` misc.c
     `cat CCTYPE` -c `cat CFLAGS` newsrc.c
     .
     .
     .
     `cat CCTYPE` -c `cat CFLAGS` phile.c
     `cat CCTYPE` -c `cat CFLAGS` mh.c
     `cat CCTYPE` -c `cat CFLAGS` mx.c
     sh -c 'rm -rf c-client.a || true'
     .
     .
     .
     Building bundled tools...
     cd mtest;make
     cc -I../c-client `cat ../c-client/CFLAGS`   -c -o mtest.o mtest.c
     cc -I../c-client `cat ../c-client/CFLAGS` -o mtest mtest.o ../c-client/ c-client.a

      
    `cat ../c-client/LDFLAGS`
     .
     .
     .
     Making Pico and Pilot
     make CC=cc -f makefile.osx
     rm -f os.h
     ln -s osdep/os-osx.h os.h
     cc   -g -DDEBUG  -Dbsd -DJOB_CONTROL   -c -o main.o main.c
     cc   -g -DDEBUG  -Dbsd -DJOB_CONTROL   -c -o attach.o attach.c
     .
     .
     .
     Making Pine.
     make CC=cc -f makefile.osx
     rm -f os.h
     ln -s osdep/os-osx.h os.h
     ./cmplhlp2.sh  < pine.hlp > helptext.h
     cc   -g -DDEBUG   -DBSDDEF -DSYSTYPE=\"OSX\"   -c -o addrbook.o addrbook.c
     cc   -g -DDEBUG   -DBSDDEF -DSYSTYPE=\"OSX\"   -c -o adrbkcmd.o adrbkcmd.c
     .
     .
     .
     Links to executables are in bin directory:
     __TEXT  __DATA  __OBJC  others  dec     hex
     3465216 253952  0       2539520 6258688 5f8000  bin/pine
     622592  12288   0       643072  1277952 138000  bin/mtest
     667648  20480   0       688128  1376256 150000  bin/imapd
     262144  12288   0       319488  593920  91000   bin/pico
     258048  12288   0       315392  585728  8f000   bin/pilot
     Done

Wow, that's a lot of output! Still at the end, it tells you that there are executables in the bin directory, so let's look in there.

[localhost:~/Documents/pine4.33] software% ls -l bin

     total 19560
     -rwxr-xr-x  2 software  staff  1363248 Apr 22 01:53 imapd
     -rwxr-xr-x  2 software  staff  1270632 Apr 22 01:53 mtest
     -rwxr-xr-x  2 software  staff   582664 Apr 22 01:53 pico
     -rwxr-xr-x  2 software  staff   577008 Apr 22 01:53 pilot
     -rwxr-xr-x  2 software  staff  6212364 Apr 22 01:55 pine

We were building pine, and in fact there is an executable pine in the bin directory, as well as a number of other applications. Installing pine now is simply copying it to /usr/local/bin with cp bin/pine /usr/local/bin. After that, pine should function as shown earlier.

There are a number of other executable applications in that bin directory, too. You might want to spend the time to find out whether they do anything that you'd find useful, but we'll leave that exercise up to you.

Also, as you might have noticed at the first listing of the directory, there is a doc directory. Things such as man pages are probably found there, so let's have a look:

[localhost:~/Documents/pine4.33] software% ls doc

     brochure.txt   mime.types    pilot.1       pine.1        tech-notes.txt
     mailcap.unx    pico.1        pine-ports    tech-notes

Great! Things that end in .# are usually man pages that belong in the man# section of the manual. Let's put the pine.1 page for pine into the appropriate man1 directory in /usr/local/man:

 [localhost:~/Documents/pine4.33] software% cp doc/pine.1 /usr/local/man/man1

    cp: /usr/local/man/man1: No such file or directory

There isn't a /usr/local/man/man1 (remember, we had to create /usr/local/bin and /usr/local/lib to install lynx).

[localhost:~/Documents/pine4.33] software% mkdir /usr/local/man/man1

     mkdir: /usr/local/man/man1: No such file or directory

Of course! We haven't made the /usr/local/man directory either. Thankfully, this install will be the only time you have to create these directories—if another application needs another directory, you'll need to create it, but you've got almost everything standard covered by now.

[localhost:~/Documents/pine4.33] software% mkdir /usr/local/man
[localhost:~/Documents/pine4.33] software% mkdir /usr/local/man/man1
[localhost:~/Documents/pine4.33] software% cp doc/pine.1 /usr/local/man/man1

And now we can try looking at the man page:

[localhost:~/Documents/pine4.33] software% man pine

     man: no entry for pine in the manual.

Remember the MANPATH variable mentioned in Chapter 12? I've forgotten to set it in this example. Again, fixing these things is best done in your .cshrc file. Setting it by hand now can be accomplished as follows:

[localhost:~/Documents/pine4.33] software% echo $MANPATH

     /Users/ray/man:/usr/local/share/man:/usr/share/man:/usr/X11R6/man
[localhost:~/Documents/pine4.33] software%
[ic:ccc]setenv MANPATH { $MANPATH} :/usr/local/man
[localhost:~/Documents/pine4.33] software%  man pine

     man: Formatting manual page...

    pine(1)                                                   pine(1)

    NAME
       pine - a Program for Internet News and Email

    SYNTAX
       pine [ options ] [ address , address ]

       pinef [ options ] [ address , address ]

    DESCRIPTION
           Pine  is  a screen-oriented message-handling tool.  In its
           default configuration, Pine offers an  intentionally  lim-
           ited  set  of functions geared toward the novice user, but
           it also has a growing list of  optional  "power-user"  and
           personal-preference  features.  pinef is a variant of Pine
           that uses function keys rather than mnemonic single-letter
           commands.  Pine's basic feature set includes:
    .
    .
    .

Finally, clean up after yourself, and put the pine stuff into your installed software directory in case you need it again:

[localhost:~/Documents/pine4.33] software% cd ../
[localhost:~/Documents] software% gzip pine4.33.tar
[localhost:~/Documents] software% mv pine4.33.tar.gz installed
[localhost:~/Documents] software% \rm -rf pine4.33

That's it! If you've been following along, you've just compiled and installed a piece of software. Is your heart racing or are your palms sweaty? Do you feel like a different person? No? Didn't think so. Most software installations, by and large, are exactly this anticlimactic.

Next, let's do a couple of quick installs that use a more standard installation protocol. They're a setup for a considerably more difficult install we'll do in the troubleshooting section of the next chapter. The first of these is libjpeg, the second is libpng. These are library packages that will be needed later to support the netpbm package—an amazingly powerful command-line graphics processing program. The complete standard invocation for configuration and compiling is usually

configure
make
make test
make install

If you read the README file for this software, you'll see it gets an additional make i n stall-lib step—always read the README and INSTALL files if they are present!

Download both libjpeg and libpng with lynx:

cd ~/Documents/
lynx -dump ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz
[ic:ccc] > jpegsrc.v6b.tar.gz
lynx -dump ftp://swrinde.nde.swri.edu/pub/png/src/libpng-1.0.10.tar.gz
[ic:ccc] > libpng-1.0.10.tar.gz

Uncompress and unarchive the libjpeg archive:

[localhost:~/Documents] software% gunzip jpegsrc.v6b.tar.gz
[localhost:~/Documents] software% tar -xf jpegsrc.v6b.tar

cd into the directory, check to see whether there's a configure file, or only a mak e file, and either ./configure, or make, as appropriate:

[localhost:~/Documents] software% cd jpeg-6b/
[localhost:~/Documents/jpeg-6b] software% ls
README         jcmarker.c      jdhuff.h       jpegint.h      maktjpeg.st
ansi2knr.1     jcmaster.c      jdinput.c      jpeglib.h      makvms.opt
ansi2knr.c     jcomapi.c       jdmainct.c     jpegtran.1     rdbmp.c
cderror.h      jconfig.bcc     jdmarker.c     jpegtran.c     rdcolmap.c
cdjpeg.c       jconfig.cfg     jdmaster.c     jquant1.c      rdgif.c
cdjpeg.h       jconfig.dj      jdmerge.c      jquant2.c      rdjpgcom.1
change.log     jconfig.doc     jdphuff.c      jutils.c       rdjpgcom.c
cjpeg.1        jconfig.mac     jdpostct.c     jversion.h     rdppm.c
cjpeg.c        jconfig.manx    jdsample.c     libjpeg.doc    rdrle.c
ckconfig.c     jconfig.mc6     jdtrans.c      ltconfig       rdswitch.c
coderules.doc  jconfig.sas     jerror.c       ltmain.sh      rdtarga.c
config.guess   jconfig.st      jerror.h       makcjpeg.st    structure.doc
config.sub     jconfig.vc      jfdctflt.c     makdjpeg.st    testimg.bmp
configure      jconfig.vms     jfdctfst.c     makeapps.ds    testimg.jpg
djpeg.1        jconfig.wat     jfdctint.c     makefile.ansi  testimg.ppm
djpeg.c        jcparam.c       jidctflt.c     makefile.bcc    testimgp.jpg
example.c      jcphuff.c       jidctfst.c     makefile.cfg   testorig.jpg
filelist.doc   jcprepct.c      jidctint.c     makefile.dj    testprog.jpg
install-sh     jcsample.c      jidctred.c     makefile.manx  transupp.c
install.doc    jctrans.c       jinclude.h     makefile.mc6   transupp.h
jcapimin.c     jdapimin.c      jmemansi.c     makefile.mms   usage.doc
jcapistd.c     jdapistd.c      jmemdos.c      makefile.sas   wizard.doc
jccoefct.c     jdatadst.c      jmemdosa.asm   makefile.unix  wrbmp.c
jccolor.c      jdatasrc.c      jmemmac.c      makefile.vc    wrgif.c
jcdctmgr.c     jdcoefct.c      jmemmgr.c      makefile.vms   wrjpgcom.1
jchuff.c       jdcolor.c       jmemname.c     makefile.wat   wrjpgcom.c
jchuff.h       jdct.h          jmemnobs.c     makelib.ds     wrppm.c
jcinit.c       jddctmgr.c      jmemsys.h      makeproj.mac   wrrle.c
jcmainct.c     jdhuff.c        jmorecfg.h     makljpeg.st    wrtarga.c

There's a configure file, so call ./configure:

[localhost:~/Documents/jpeg-6b] software% ./configure

     checking for gcc... no
     checking for cc... cc
     checking whether the C compiler (cc  ) works... yes
     checking whether the C compiler (cc  ) is a cross-compiler... no
     checking whether we are using GNU C... yes
     checking how to run the C preprocessor... cc -E -traditional-cpp
     checking for function prototypes... yes
     checking for stddef.h... yes
     checking for stdlib.h... yes
     checking for string.h... yes
     checking for size_t... yes
     checking for type unsigned char... yes
     checking for type unsigned short... yes
     checking for type void... yes
     checking for working const... yes
     checking for inline... __inline__
     checking for broken incomplete types... ok
     checking for short external names... ok
     checking to see if char is signed... yes
     checking to see if right shift is signed... yes
     checking to see if fopen accepts b spec... yes
     checking for a BSD compatible install... /usr/bin/install -c
     checking for ranlib... ranlib
     checking libjpeg version number... 62
     creating ./config.status
     creating Makefile
     creating jconfig.h

configure runs and drops you back to the command line with no complaints, so now it's time to run make:

[localhost:~/Documents/jpeg-6b] software% make

     cc -O2  -I.   -c -o jcapimin.o jcapimin.c
     cc -O2  -I.   -c -o jcapistd.o jcapistd.c
     cc -O2  -I.   -c -o jctrans.o jctrans.c
     cc -O2  -I.   -c -o jcparam.o jcparam.c
     cc -O2  -I.   -c -o jdatadst.o jdatadst.c
     .
     .
     .
     rm -f libjpeg.a
     ar rc libjpeg.a  jcapimin.o jcapistd.o jctrans.o jcparam.o jdatadst.o      jcinit.o jcmaster.o jcmarker.o jcmainct.o
     [ic:ccc]jcprepct.o jccoefct.ojccolor.o      jcsample.o jchuff.o jcphuff.o jcdctmgr.o
     [ic:ccc]jfdctfst.o jfdctflt.o jfdctint.o      jdapimin.o jdapistd.o jdtrans.o jdatasrc.o
     [ic:ccc]jdmaster.o jdinput.o jdmarker.o      jdhuff.o jdphuff.o jdmainct.o jdcoefct.o
     [ic:ccc]jdpostct.o jddctmgr.o jidctfst.o      jidctflt.o jidctint.o jidctred.o jdsample.o
     [ic:ccc]jdcolor.o jquant1.o jquant2.o      jdmerge.o jcomapi.o jutils.o jerror.o jmemmgr.o jmemnobs.o
     ranlib libjpeg.a
     cc -O2  -I.   -c -o cjpeg.o cjpeg.c
     cc -O2  -I.   -c -o rdppm.o rdppm.c
     .
     .
     .
     cc -O2  -I.   -c -o wrjpgcom.o wrjpgcom.c
     cc  -o wrjpgcom wrjpgcom.o

Again, you arrive back at the command line, so it's time to try make test:

[localhost:~/Documents/jpeg-6b] software% make test

     rm -f testout*
     ./djpeg -dct int -ppm -outfile testout.ppm  ./testorig.jpg
     ./djpeg -dct int -bmp -colors 256 -outfile testout.bmp  ./testorig.jpg
     ./cjpeg -dct int -outfile testout.jpg  ./testimg.ppm
     ./djpeg -dct int -ppm -outfile testoutp.ppm ./testprog.jpg
     ./cjpeg -dct int -progressive -opt -outfile testoutp.jpg ./testimg.ppm
     ./jpegtran -outfile testoutt.jpg ./testprog.jpg
     cmp ./testimg.ppm testout.ppm
     cmp ./testimg.bmp testout.bmp
     cmp ./testimg.jpg testout.jpg
     cmp ./testimg.ppm testoutp.ppm
     cmp ./testimgp.jpg testoutp.jpg
     cmp ./testorig.jpg testoutt.jpg

If there was a problem, make test would have spit out some error diagnostics and told you that it had encountered trouble. Because it didn't, you're on to make install:

[localhost:~/Documents/jpeg-6b] software% make install

     /usr/bin/install -c cjpeg /usr/local/bin/cjpeg
     /usr/bin/install -c djpeg /usr/local/bin/djpeg
     /usr/bin/install -c jpegtran /usr/local/bin/jpegtran
     /usr/bin/install -c rdjpgcom /usr/local/bin/rdjpgcom
     /usr/bin/install -c wrjpgcom /usr/local/bin/wrjpgcom
     /usr/bin/install -c -m 644 ./cjpeg.1 /usr/local/man/man1/cjpeg.1
     /usr/bin/install -c -m 644 ./djpeg.1 /usr/local/man/man1/djpeg.1
     /usr/bin/install -c -m 644 ./jpegtran.1 /usr/local/man/man1/jpegtran.1
     /usr/bin/install -c -m 644 ./rdjpgcom.1 /usr/local/man/man1/rdjpgcom.1
     /usr/bin/install -c -m 644 ./wrjpgcom.1 /usr/local/man/man1/wrjpgcom.1

Notice that it's making use of the /usr/local/man/man1 directory that you created earlier. If you hadn't, it would be complaining here.

Finally, if you read the README, you'd see that we need a make install-lib step here, too:

[localhost:~/Documents/jpeg-6b] software% make install-lib

     /usr/bin/install -c -m 644 jconfig.h /usr/local/include/jconfig.h
     /usr/bin/install: /usr/local/include/jconfig.h: No such file or directory
     make: *** [install-headers] Error 1

What did I say about that installer not creating directories? Now it needs a /usr/local/include directory as well.

[localhost:~/Documents/jpeg-6b] software% mkdir /usr/local/include
[localhost:~/Documents/jpeg-6b] software% make install-lib

     /usr/bin/install -c -m 644 jconfig.h /usr/local/include/jconfig.h
     /usr/bin/install -c -m 644 ./jpeglib.h /usr/local/include/jpeglib.h
     /usr/bin/install -c -m 644 ./jmorecfg.h /usr/local/include/jmorecfg.h
     /usr/bin/install -c -m 644 ./jerror.h /usr/local/include/jerror.h
     /usr/bin/install -c -m 644 libjpeg.a /usr/local/lib/libjpeg.a

Then you're done. If you're being neat, delete the directory you've been working in, gzip the tar file, and store it in your installed directory.

Now let's take a look at what you just did. Other than creating a directory to fix the not-quite-functional installer, the entire process was: ./configure, which guessed a few settings about your machine, and then a series of make, make test, make install, and make install-lib. Other than the ./configure, the actual program called in each case was make, and it was directed to make different things with each call. The identities of these things are defined by the software author in a control file called a makefile, and named, unsurprisingly, either Makefile or makefile. With any well-written software package, the makefile will direct make with no arguments to compile the software with default settings. Frequently, but not always, there will be a test suite provided that can be invoked with make test. Finally, an installer routine will be invoked, by convention, with make install. In the case of libjpeg, the package provides both a few small executables, and some library functions for other software, should you want them. The basic make install process puts the small executables in /usr/local/bin, but doesn't install the libraries because not everyone wants them. Therefore, there's an optional make install-lib step to install the libraries and support files. If you've followed along this far, your /usr/local structure should be fairly mature, and most software won't need you to create any more directories for it.

Note

Some software that you try to install will want you to use the bsdmake version of the make program instead of just make. Apple has also provided a separate gnumake executable, should you find software that wants gnumake or gmake. If you find this requirement in a README file, just substitute bsdmake or gnumake for make in the discussion. If you find a program that outputs what seems to be incomprehensible gibberish when you type make, give the other versions a try and see whether they do any better.

The configure step is typical as well, although the mechanics will vary depending on the application you're compiling. Most of the time, it can either examine your system and determine, or make an educated guess about, configuration options. Occasionally, it will require you to provide it with some information, but in most cases it's all right to accept the default answers suggested by configure if you don't have a better answer or don't know the answer.

Finally, let's run through the install of libpng because without it, the broken netpbm we're going to fix in the next section is truly hopeless:

[localhost:~/Documents/libpng-1.0.10] software% gunzip libpng-1.0.10.tar.gz
[localhost:~/Documents/libpng-1.0.10] software% tar -xv libpng-1.0.10.tar
[localhost:~/Documents/libpng-1.0.10] software% cd libpng-1.0.10
[localhost:~/Documents/libpng-1.0.10] software% ls

     ANNOUNCE    Y2KINFO      png.5        pngerror.c   pngrio.c     pngvcrd.c
     CHANGES     configure    png.c        pnggccrd.c   pngrtran.c   pngwio.c
     INSTALL     contrib      png.h        pngget.c     pngrutil.c   pngwrite.c
     KNOWNBUG    example.c    pngasmrd.h   pngmem.c     pngset.c     pngwtran.c
     LICENSE     libpng.3     pngbar.jpg   pngnow.png   pngtest.c    pngwutil.c
     README      libpng.txt   pngbar.png   pngpread.c   pngtest.png  projects
     TODO        libpngpf.3   pngconf.h    pngread.c    pngtrans.c   scripts

It has a configure, so use it:

[localhost:~/Documents/libpng-1.0.10] software% ./configure

       There is no "configure" script for Libpng-1.0.10.  Instead, please
       copy the appropriate makefile for your system from the "scripts"
       directory.  Read the INSTALL file for more details.

Another nonstandard installation, so follow the instructions:

[localhost:~/Documents/libpng-1.0.10] software% ls scripts

     SCOPTIONS.ppc    makefile.bor        makefile.knr        makefile.std
     descrip.mms      makefile.cygwin     makefile.linux      makefile.sunos
     libpng.icc       makefile.dec        makefile.macosx     makefile.tc3
     makefile.acorn   makefile.dj2        makefile.mips       makefile.vcawin32
     makefile.aix     makefile.gcc        makefile.msc        makefile.vcwin32
     makefile.amiga   makefile.gcmmx      makefile.os2        makefile.watcom
     makefile.atari   makefile.hpgcc      makefile.sco        makevms.com
     makefile.bc32    makefile.hpux       makefile.sggcc      pngdef.pas
     makefile.bd32    makefile.ibmc       makefile.sgi        pngos2.def
     makefile.beos    makefile.intel      makefile.solaris    smakefile.ppc

Fantastic! A macosx file! Copy it to the libpng directory as makefile and run make, make test (the output of which we're omitting here), and make install:

[localhost:~/Documents/libpng-1.0.10]
[ic:ccc]software% cp scripts/makefile.macosx ./makefile
[localhost:~/Documents/libpng-1.0.10] software% make
     cc -I../zlib -O    -c -o png.o png.c
     cc -I../zlib -O    -c -o pngset.o pngset.c
     cc -I../zlib -O    -c -o pngget.o pngget.c
     .
     .
     .
     cc -I../zlib -O    -c -o pngerror.o pngerror.c
     cc -I../zlib -O    -c -o pngpread.o pngpread.c
     ar rc libpng.a  png.o pngset.o pngget.o pngrutil.o pngtrans.o      pngwutil.o pngread.o pngrio.o pngwio.o pngwrite.o pngrtran.o      pngwtran.o pngmem.o pngerror.o pngpread.o
     ranlib libpng.a
     cc -I../zlib -O    -c -o pngtest.o pngtest.c
     cc -o pngtest -I../zlib -O  pngtest.o -L. -L../zlib -lpng -lz
     /usr/bin/ld: warning -L: directory name (../zlib) does not exist

It had a warning, but no errors! You can run make test here to verify that it works—we'll just show the output of make install:

[localhost:~/Documents/libpng-1.0.10] software% make install

     mkdir: /usr/local/include: File exists
     make: [install] Error 1 (ignored)
     mkdir: /usr/local/lib: File exists
     make: [install] Error 1 (ignored)
     cp png.h /usr/local/include
     cp pngconf.h /usr/local/include
     chmod 644 /usr/local/include/png.h
     chmod 644 /usr/local/include/pngconf.h
     cp libpng.a /usr/local/lib
     chmod 644 /usr/local/lib/libpng.a

[localhost:~/Documents] software%

It survived the whole thing without you needing to do anything other than follow some simple instructions. The vast majority of Unix software installs are this easy. Unfortunately, OS X isn't as well supported in the configure scripts as most Unix flavors just yet, but after it is, expect that 90% of all software will install with ./configure, make, make test, make i n stall, and no further interaction from you.

You can make more installs work using the configure command by copying some files that Apple has provided into the software directory where you will be running configure. None of the installs shown here benefits from this, but copying /usr/ libexec/config.guess and /usr/libexec/config.sub to the directory where you run configure might help with some compilations.

Summary | Next Section

Previous Section