< Day Day Up > |
Installing Software at the Command LineThe majority of the Unix software you'll find that hasn't been specifically made for Mac OS X is created by other users just like you. Some of them are professional programmers, but the vast majority of them are simply hobbyists who've put together an application because they wanted a program that did something, and they've made it available for you to install out of the sense of team spirit that pervades the Unix and open source communities. Because of the wide range of individuals involved, the possibilities for how the software 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 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.
DownloadingYou'll find Unix software being distributed in Usenet newsgroups, on web pages, FTP servers, through email, 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, to your local machine. You've got all the tools necessary to accomplish any of these in the command-line programs discussed here and in the previous chapter, as well as in the GUI clients covered earlier. While acquiring software, keep in mind that things will go smoothest if
UnarchivingSome software comes as source code (the language that compilers read) that explains to the compiler how to create a finished program. Some comes as final executable programs. Either way, most software comes 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. 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.
If you've downloaded a precompiled application that needs you only to unpack it in place or 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, skip to the next section on compiling software. Installing a Precompiled Binary by Unarchiving and Putting It Where It Belongs: lynxThe 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.macosxunleashed.com/downloads/. Before you install lynx, we recommend that you make a change in your system's configuration that helps keep your system safe from malicious software and accidents during software installs. Use the Accounts control pane discussed in Chapter 8, "Customizing User and System Settings," to create a new user to own all your software. There we showed how to create the unprivileged software user with the custom group tire. This is the user who will own and install our programs for us. Because software is not an administrative user and has privileges only in her home directory and in /usr/local/, software can't damage anything outside those locations. At worst, a malicious script or accident at the keyboard will just screw up what software's already installed, leaving the rest of the machine safe. 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. If you're using unprivileged user software with group tire, ifrom the command line, the process looks like the following: brezup:ray testing $ su Password: brezup:root testing # cd /usr brezup:root usr # chown software.tire /usr/local brezup:root usr # ls -ld local drwxr-xr-x 4 software tire 92 Apr 21 22:00 local
The lynx application should now be executable and behave just as detailed in Chapter 13, "Using Common Command-Line Applications and Application Suites," although there is a bit of weirdness with the man page that we're going to have to fix in the next few pages. Before you go on, stop and think fori a moment about what you've just done. If the terminal is still a strange place to you, you might be feeling as if you've just uttered some magic incantations and not be too sure you could do this again without the explicit instructions. Most things you come across will have instructions that are relatively explicit, but that's not the point. All that you've done is this: You've downloaded the software you're used to doing that for other software installs in your web browser, FTP client, or the like you've done nothing different here. Then you unpackaged it nothing new there either you've used StuffIt Expander before, right? Finally, you made a few new directories and copied the software where you wanted it to go. None of this was difficult for you and it won't be difficult for you in the future either. Don't let the fact that you're using unfamiliar tools now get in the way of the fact that you know what to do every step of the way. Soon you'll find this way of working to be just as second nature to you as double-clicking an "install" icon. Building Software from Source Code: CompilingCompiling source code is 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 an application of what you've learned in the last few chapters and this one and the introduction of new programs for you to use. Actually, 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, makeLet's start with an example of a simple software install that requires compilation things can get more complicated than this, but for many applications written by conscientious programmers, these steps will suffice. Installs shown here are also done assuming that 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 want to follow along with this example, the pine package shown here can be downloaded from ftp://ftp.cac.washington.edu/pine/pine.tar.gz. The simplest way to do this is with curl: cd ~/Documents curl -O ftp://ftp.cac.washington.edu/pine/pine.tar.gz gunzip pine.tar.gz tar -xf pine.tar
ftp://ftp.cac.washington.edu/pine/pine.tar.gz is always a link to the most recent version, so pine might have advanced beyond 4.61 by the time you're reading this. We know pine4.61 compiles okay, so if you download a more recent version and have problems, you should be able to get 4.61 from its old directory most likely at the URL ftp://ftp.cac.washington.edu/pine/old/pine4.61.tar.gz. After you've downloaded and unpacked your distribution, it's time to dig in and build some software. brezup:software source $ cd pine4.61/ brezup:software pine4.61 $ ls -l total 136 -rw-r--r-- 1 software tire 2866 May 7 2004 CPYRIGHT -rw-r--r-- 1 software tire 12229 May 7 2004 README -rwxr-xr-x 1 software tire 18070 May 17 2004 build -rwxr-xr-x 1 software tire 6039 Mar 15 1996 build.cmd -rwxr-xr-x 1 software tire 17118 May 7 2004 buildcyg drwxr-xr-x 10 software tire 340 Apr 27 2004 contrib drwxr-xr-x 13 software tire 442 Jul 15 13:38 doc drwxr-xr-x 16 software tire 544 Jul 15 14:29 imap -rw-r--r-- 1 software tire 1574 Oct 3 2003 makefile drwxr-xr-x 5 software tire 170 Jul 14 15:28 packages drwxr-xr-x 86 software tire 2924 Jul 14 15:37 pico drwxr-xr-x 101 software tire 3434 Jul 15 13:37 pine There's no file named configure, so try make: brezup:software pine4.61 $ 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, which points you to docs/pine-ports, you'll observe that an osx option already is available, so give that a try: brezup:software pine4.61 $ ./build osx make args are CC=cc osx <much output deleted> Building c-client for osx... echo `cat SPECIALS` > c-client/SPECIALS cd c-client;make osx EXTRACFLAGS='\ EXTRALDFLAGS='\ EXTRADRIVERS='mbox'\ . . . Building OS-dependent module If you get No such file error messages for files x509.h, ssl.h, pem.h, buffer.h, bio.h, and crypto.h, that means that OpenSSL is not installed on your system. Either install OpenSSL first or build with command: make osx SSLTYPE=none `cat CCTYPE` -c `cat CFLAGS` `cat OSCFLAGS` -c osdep.c `cat CCTYPE` -c `cat CFLAGS` mail.c . . . Building bundled tools... cd mtest;make cc -I../c-client `cat ../c-client/CFLAGS` -c -o mtest.o mtest.c . . . 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 and rpload/rpdump. make CC=cc LDAPLIBS=-lldap LDAPCFLAGS=-DENABLE_LDAP -f makefile.osx rm -f os.h ln -s osdep/os-osx.h os.h ./cmplhlp2.sh < pine.hlp > helptext.h cc -g -DDEBUG -DDEBUGJOURNAL -DENABLE_LDAP -Dconst= -DSYSTYPE=\"OSX\" -c -o addrbook .o addrbook.c . . . Links to executables are in bin directory: __TEXT __DATA __OBJC others dec hex 4272128 319488 0 3248128 7839744 77a000 bin/pine 684032 12288 0 684032 1380352 151000 bin/mtest 724992 77824 0 720896 1523712 174000 bin/imapd 278528 12288 0 286720 577536 8d000 bin/pico 274432 12288 0 282624 569344 8b000 bin/pilot 946176 20480 0 946176 1912832 1d3000 bin/rpdump 950272 20480 0 950272 1921024 1d5000 bin/rpload 684032 12288 0 679936 1376256 150000 bin/mailutil 684032 12288 0 679936 1376256 150000 bin/ipop2d 688128 12288 0 679936 1380352 151000 bin/ipop3d Done Wow, that's a lot of output! If you were watching closely, you'll have seen some warnings fly by in there. But as long as it didn't explicitly say "Error" and, at the end, it tells you that there are executables in the bin directory, you're in good shape. Let's look in the bin directory and see what you've got. brezup:software pine4.61 # ls -l bin total 36848 total 38456 -rwxr-xr-x 2 software tire 1453756 Jan 5 12:25 imapd -rwxr-xr-x 2 software tire 1368304 Jan 5 12:25 ipop2d -rwxr-xr-x 2 software tire 1375420 Jan 5 12:25 ipop3d -rwxr-xr-x 2 software tire 1371568 Jan 5 12:25 mailutil -rwxr-xr-x 2 software tire 1372536 Jan 5 12:25 mtest -rwxr-xr-x 2 software tire 566500 Jan 5 12:26 pico -rwxr-xr-x 2 software tire 559768 Jan 5 12:26 pilot -rwxr-xr-x 2 software tire 7787980 Jan 5 12:28 pine -rwxr-xr-x 2 software tire 1902860 Jan 5 12:28 rpdump -rwxr-xr-x 2 software tire 1910980 Jan 5 12:28 rpload 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. brezup:software pine4.61 $ cp bin/pine /usr/local/bin/ A number of other executable applications are in that bin directory, too. You might want to spend the time to find out whether they do anything that you'd find useful for example, along with pine, you've just built pico, which is a popular text editor that's been gaining on emacs and vi for quite a while. If you check the version of pico, a fairly popular and friendly terminal-based text editor included with Mac OS X 10.2 and 10.3, you'll find that it's version 2.5, and you've just built pico version 4.6 possibly a worthwhile upgrade. We'll leave the exercise of reading about the rest of the utilities you've just built up to you. To make this a little easier, 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 take a look: brezup:software pine4.61 $ ls doc brochure.txt pico.1 pine.1 tech-notes mailcap.unx pilot.1 rpdump.1 tech-notes.txt mime.types pine-ports rpload.1 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. If you didn't already create the /usr/local/man/man1 directory when you installed lynx earlier, you'll get a response something like this: brezup:software pine4.61 $ cp doc/pine.1 /usr/local/man/man1/ cp: /usr/local/man/man1: No such file or directory In such a case, you simply need to make the directory: brezup:software pine4.61 $ mkdir /usr/local/man/man1 mkdir: /usr/local/man/man1: No such file or directory Of course, if you didn't create these directories already, there's probably no /usr/local/man directory either. Thankfully, you only have to do this kind of directory creation steps once most other command-line software will want the same directory structure, and this will be the only time you have to create these directories. brezup:software pine4.61 $ mkdir /usr/local/man brezup:software pine4.61 $ mkdir /usr/local/man/man1 Alternatively, you could make both directories with the same command, by using the -p "make intermediate directories" (that is make the entire path) option of mkdir: brezup:software pine4.61 $ mkdir -p /usr/local/man/man1 If another application needs another directory, of course you'll need to create it, but you've got almost everything standard covered by now. brezup:software pine4.61 $ cp doc/pine.1 /usr/local/man/man1 And now we can try looking at the man page. If you're using a version of Mac OS X that doesn't include the manpath command (versions more recent than 10.2.5 appear to include it) or you don't have /usr/local/bin added to your executable search path, you'll see something like the following; otherwise, you should see the man page for pine appear, just like any other man page on your system: brezup:software pine4.61 $ man pine man: no entry for pine in the manual.
This error indicates that the man command doesn't know where to find the man page for pine specifically, that it hasn't been informed of the /usr/local/man/man1 directory that you just put it in. On recent versions of Mac OS X, all you need to do to make that directory visible to man is to include the /usr/local/bin directory in your executable search path (and perhaps fix the configuration as mentioned in the preceding caution), and the manpath command will automatically provide man with likely sounding directory names that are near the executable directories.
If for some reason you really want to stuff man pages off in weird corners where the manpath command can't find them automatically, you can always set the MANPATH environment variable as a way of explicitly telling man where to look.
In this case, I've deliberately forgotten to set the executable search path to include /usr/local/bin, so the manpath command doesn't know about /usr/local/man as a place to find man pages. Again, fixing these things is best done in your .bashrc or .cshrc file or the system equivalents. Setting it by hand now can be accomplished as follows: brezup:software pine4.61 $ echo $PATH /bin:/sbin:/usr/bin:/usr/sbin brezup:software pine4.61 $ PATH=$PATH:/usr/local/bin brezup:software pine4.61 $ echo $PATH /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin brezup:software pine4.61 $ man pine 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 con- figuration, Pine offers an intentionally limited 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: . . . If you install other programs from the bin directory, you'll want to copy their man pages as well. Finally, clean up after yourself, and put the pine stuff into your installed software directory in case you need it again: brezup:software pine4.61 $ make clean ./build clean make args are CC=cc clean Cleaning c-client and imapd Removing old processed sources and binaries... <deletia> Cleaning Pine rm -f *.o os.h os.c helptext.c helptext.h pine pine.exe rpdump rpdump.exe rpload rpload.exe <more deletia> Cleaning pico rm -f *.a *.o *~ pico_os.c os.h pico pico.exe pilot pilot.exe <and more deletia> Done brezup:software pine4.61 $ cd ../ brezup:software source $ tar -cf installed_pine4.61.tar pine4.61/ brezup:software source $ gzip installed_pine4.61.tar brezup:software source $ mkdir installed brezup:software source $ mv installed_pine4.61.tar.gz installed/ brezup:software source $ \rm -rf pine4.61 brezup:software source $ \rm -rf pine.tar 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 collection of steps to get you set up for a considerably more difficult install we'll do in the troubleshooting section of this chapter. The first of these is libjpeg and 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 the following: configure make make test make install If you read the README file for this software, you'll see it gets an additional make install-lib step always read the README and INSTALL files if they are present!
Yes, that's a bunch of files it's nothing to worry about, though. The configuration and build scripts put together by the author will take care of the details; all you need to do is remember the general steps for building and respond as requested if there's something the software or READMEs ask you to do. There's a configure file, so call ./configure: brezup:software jpeg-6b $ ./configure checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking how to run the C preprocessor... gcc -E 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: brezup:software jpeg-6b $ make gcc -O2 -I. -c -o jcapimin.o jcapimin.c gcc -O2 -I. -c -o jcapistd.o jcapistd.c gcc -O2 -I. -c -o jctrans.o jctrans.c gcc -O2 -I. -c -o jcparam.o jcparam.c gcc -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 jcprepct.o jccoefct.ojccolor.o \ jcsample.o jchuff.o jcphuff.o jcdctmgr.o jfdctfst.o jfdctflt.o jfdctint.o \ jdapimin.o jdapistd.o jdtrans.o jdatasrc.o jdmaster.o jdinput.o jdmarker.o \ jdhuff.o jdphuff.o jdmainct.o jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o \ jidctflt.o jidctint.o jidctred.o jdsample.o jdcolor.o jquant1.o jquant2.o \ jdmerge.o jcomapi.o jutils.o jerror.o jmemmgr.o jmemnobs.o ranlib libjpeg.a gcc -O2 -I. -c -o cjpeg.o cjpeg.c gcc -O2 -I. -c -o rdppm.o rdppm.c . . . gcc -O2 -I. -c -o wrjpgcom.o wrjpgcom.c gcc -o wrjpgcom wrjpgcom.o Again, you arrive back at the command line, so it's time to try make test: brezup:software jpeg-6b $ 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 ready to move on to make install: brezup:software jpeg-6b $ 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 using the /usr/local/man/man1 directory that you created earlier. If you hadn't done so, it would be complaining here.
Finally, if you read the README, you'd see that we need a make install-lib step here, too: brezup:software jpeg-6b $ 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: brezup:software jpeg-6b $ mkdir /usr/local/include brezup:software jpeg-6b $ 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 finished. To tidy things up, make clean, delete the original tar file, tar and then delete the directory you've been working in, gzip the new 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 (called with no arguments) to compile the software with default settings. Frequently, but not always, a test suite is provided that can be invoked with make test. Finally, an installer routine is 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.
The configure step is typical as well, although the mechanics vary depending on the application you're compiling. Most of the time, configure can examine your system and either determine or make an educated guess about configuration options. Occasionally, it requires 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: brezup:software source $ gunzip libpng-1.2.8-config.tar.gz brezup:software source $ tar -xf libpng-1.2.8-config.tar brezup:software source $ cd libpng-1.2.8-config brezup:software libpng-1.2.8 $ ls ANNOUNCE config.sub png.c pngrutil.c CHANGES configure png.h pngset.c INSTALL configure.ac pngbar.jpg pngtest.c KNOWNBUG contrib pngbar.png pngtest.png LICENSE depcomp pngconf.h pngtrans.c Makefile.am example.c pngerror.c pngvcrd.c Makefile.in install-sh pnggccrd.c pngwio.c README libpng.3 pngget.c pngwrite.c TODO libpng.txt pngmem.c pngwtran.c Y2KINFO libpngpf.3 pngnow.png pngwutil.c aclocal.m4 ltmain.sh pngpread.c projects autogen.sh missing pngread.c scripts config.guess mkinstalldirs pngrio.c test-pngtest.sh config.h.in png.5 pngrtran.c It has a configure, so use it: brezup:software libpng-1.2.8 $ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no ... config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands brezup:software libpng-1.2.8 $ Well, that's pleasant. It seems to have configured itself. Now it's time to try make: brezup:software libpng-1.2.5 $ make make all-am if /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT png.lo -MD -MP -MF ".deps/png.Tpo" \ -c -o png.lo `test -f 'png.c' || echo './'`png.c; \ then mv ".deps/png.Tpo" ".deps/png.Plo"; \ else rm -f ".deps/png.Tpo"; exit 1; \. ... echo R_opts=\"-Wl,-rpath,/usr/local/lib\"; \ echo libs=\"-lpng12 -lz -lm\"; \ cat ./scripts/libpng-config-body.in ) > libpng-config cp libpng-config libpng12-config brezup:software libpng-1.2.8 $ If I had been working with an earlier version of libpng, that command would have stopped with an error, and I would have had to search around the documentation and FTP site to discover that there was an updated, custom makefile available for Mac OS X. Now, due to the magic of open source development, someone's fixed the bug for me and it all appears to have worked neatly. Because there were no errors, and the installer doesn't appear to have a make test step, we're on to make install: brezup:software libpng-1.2.8 $ make install /bin/sh ./mkinstalldirs /usr/local/bin /usr/bin/install -c libpng-config /usr/local/bin/libpng-config /usr/bin/install -c libpng12-config /usr/local/bin/libpng12-config /bin/sh ./mkinstalldirs /usr/local/lib ... ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable during execution See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- ... mkdir -p -- /usr/local/man/man5 /usr/bin/install -c -m 644 ./png.5 /usr/local/man/man5/png.5 /bin/sh ./mkinstalldirs /usr/local/include/libpng mkdir -p -- /usr/local/include/libpng /usr/bin/install -c -m 644 png.h /usr/local/include/libpng/png.h /usr/bin/install -c -m 644 pngconf.h /usr/local/include/libpng/pngconf.h brezup:software libpng-1.2.8 $ All done. You've survived yet another software install. By now, this should be starting to look a bit more tedious than double-clicking an installer but no more threatening. Unfortunately, Mac OS X isn't as well supported in the configure scripts as some major Unix flavors just yet, so there are still a few rough spots like the makefile you would have needed to discover with the earlier versions. It's catching on quickly though, so soon, expect that 90% of all software will install with ./configure, make, make test, and make install, and no further interaction from you.
Installing the fink Ports and Packages ManagerFink is a porting project, and fink is the software package manager it has produced for Mac OS X. It's an open source community project intended to bring the wide wild world of Unix applications to Mac OS X at a level of difficulty that the average Macintosh user won't find frustrating or, hopefully, even annoying. Because this book is being written on the bleeding edge of the release of Mac OS X 10.4, fink itself hasn't yet been updated to work with Tiger. Overall this isn't a large problem; fink will work in Tiger much like it works in earlier versions of the Mac OS, it simply might have some different defaults and might require a few months after the release to come up to full speed with respect to supporting applications. Hopefully, by the time you're reading this, everything will be working exactly as shown. If not, check the fink home page periodically (http://fink.sourceforge.net/), because being able to use a package manager to facilitate large, multipackage software installs really is a huge convenience. There's even a GUI front end (available from http://finkcommander.sourceforge.net/) that makes the installation of hundreds of useful applications that were historically installed from the command line into a point-and-click experience.
When using fink, you have the choice of installing precompiled binary applications out of Fink's library or using fink as an automated system to work out and apply compilation details, building the software on your own system. Because the binary application library always lags a few versions behind what's available through the source distribution, and sometimes doesn't even provide versions of some software, we'll cover how to use the source distribution in this chapter. Using the source distribution is relatively easy easier than any of the command-line software installations you've seen. Using the binary distribution is even easier, if you've a reason to prefer to work with it (for example, it doesn't require that you have the developer tools installed). Because we seem to constantly be revising this book on the cusp of major operating system changes, we've gotten used to the fact that the corresponding Fink version is rarely finished when we're writing. As a result, you get to have the most grueling introduction possible to using fink pretty much building everything from scratch, straight from the command line. Don't let this bother you. The Fink system is a study in automation the "most grueling introduction possible" requires you to type about a half-dozen commands, press the Return key to accept a few default prompts, and go have dinner. After you've done this, you can build entire applications with the simple command fink install <packagename>. The maintainers of Fink application porting projects do all the hard work of figuring out the quirks of making software work with Mac OS X and then package it so that all the interdependencies are known and codified. When a package is made available, all you need to do is ask fink to install it, and, along with any other required software, it'll be automatically downloaded, configured, and installed.
The first step in using fink to install software is to install fink itself. You need to do this only once, and despite the large volume of interaction we show here, it's really a simple process. brezup:ray Software $ mkdir finkcvs brezup:ray Software $ cd finkcvs brezup:ray finkcvs $ cvs -d:pserver:anonymous@cvs.fink.sourceforge.net:/cvsroot/fink login (Logging in to anonymous@cvs.fink.sourceforge.net) CVS password: The CVS password for anonymous, download-only access is empty, so just press the Return key at the password prompt. brezup:ray finkcvs $ cvs -d:pserver:anonymous@ cvs.fink.sourceforge.net:/cvsroot/fink checkout fink cvs server: Updating fink U fink/.cvsignore U fink/AUTHORS U fink/COPYING U fink/ChangeLog U fink/INSTALL U fink/INSTALL.html . . . cvs server: Updating fink/update U fink/update/ChangeLog U fink/update/Makefile.in.in U fink/update/config.guess U fink/update/config.sub U fink/update/ltconfig U fink/update/ltmain.sh Alternatively, you might be able to avoid the CVS checkout step and download a tarfile of the base fink installer source from Fink's downloads page as well (http://fink.sourceforge.net/download/srcdist.php). This has the advantage of getting you the base system in a lump, but it will be several revisions behind the most recent, and you'll have to remove and install new versions to update, rather than simply being able to ask the CVS version to update and rebuild itself. Regardless of how you obtain the base distribution, your next step is to cd in to the directory (which might be named different things, depending on how you acquired it) and run the bootstrap.sh script to get everything configured. brezup:ray finkcvs $ cd fink brezup:ray fink $ ./bootstrap.sh Welcome to Fink. This script will install Fink into a directory of your choice, setup a configuration file and conduct a bootstrap of the installation. Found perl version 5.008004. Checking package... looks good. Checking system... powerpc-apple-darwin8.0.0b2 This system was not released at the time this Fink release was made. Prerelease versions of Mac OS X might work with Fink, but there are no guarantees. Distribution 10.3 Fink must be installed and run with superuser (root) privileges. Fink can automatically try to become root when it's run from a user account. Avaliable methods: (1) Use sudo (2) Use su (3) None, fink must be run as root Choose a method: [1] 3 ERROR: Can't continue as non-root. brezup:ray fink $ fink must have some way to run by the root user so that it can modify various things in semiprivileged directories. This is a poor design, but it's because Apple put things that shouldn't be root-owned, in places that only root can write. The bootstrap.sh script halted here because I don't like giving software the option of "becoming root itself," and I forgot to su or sudo at the start of the bootstrap.sh process. fink is capable of updating many Apple-supplied packages to more current versions, and the maintainers seem committed to keeping their software as Apple-friendly as possible. They appear to be making a conscientious effort to keep their installers from conflicting with Apple installations while providing updated versions of Apple-supplied software. I'm not a big fan of running installations as root, but given the level of attention that the fink project maintainers are paying to the quality of their code, I feel better about giving this software the go-ahead. brezup:ray fink $ sudo ./bootstrap.sh Password: Welcome to Fink. ... Fink must be installed and run with superuser (root) privileges. Fink can automatically try to become root when it's run from a user account. Avaliable methods: (1) Use sudo (2) Use su (3) None, fink must be run as root Choose a method: [3] 3 Checking cc... looks good. Checking make... looks good. Checking head... looks good. Please choose the path where Fink should be installed. [/sw] /sw OK, installing into '/sw'. Creating directories... mkdir -p /sw mkdir /sw/etc mkdir /sw/etc/alternatives . . . mkdir /sw/fink/10.2/local/main/finkinfo mkdir /sw/fink/10.2/local/main/binary-darwin-powerpc Copying package descriptions... . . . USAGE.html ChangeLog VERSION fink.in fink.8.in install.sh setup.sh postinstall.pl.in perlmod update mirror Creating initial configuration... OK, I'll ask you some questions and update the configuration file in '/sw/etc/fink.conf'. A considerable number of configuration choices follow, enabling you to suggest preferred locations of where you want to download various software bits as the system needs them. If you change your mind later, you can modify these choices with the command fink configure. Make choices that are appropriate for your system I've mostly just chosen the default values here. In what additional directory should Fink look for downloaded tarballs? [] (1) Quiet (don't show download stats) (2) Low (don't show tarballs being expanded) (3) Medium (shows almost everything) (4) High (shows everything) How verbose should Fink be? [4] 4 Proxy/Firewall settings Enter the URL of the HTTP proxy to use, or 'none' for no proxy. The URL should start with http:// and may contain username, password or port specifications. [none] none Enter the URL of the proxy to use for FTP, or 'none' for no proxy. The URL should start with http:// and may contain username, password or port specifications. [none] none Use passive mode FTP transfers (to get through a firewall)? [Y/n] Y Mirror selection Choose a continent: (1) Africa (2) Asia (3) Australia (4) Europe (5) North America (6) South America, Middle America and Caribbean Your continent? [1] 5 Choose a country: (1) No selection - display all mirrors on the continent (2) Canada (3) Mexico (4) United States Your country? [1] 4 A dozen or so configuration options sets go by, but despite the volume of options, accepting the defaults appears to work just fine. Next the program starts downloading and building the bits and pieces that it needs to construct itself. Self-collecting and building software neat, huh? BOOTSTRAP PHASE ONE: download tarballs. pkg gettext version ### pkg gettext version 0.10.40-3 pkg tar version ### ... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl -I/sw/bootstrap/include \ -g -O2 -c `test -f hash.c || echo './'`hash.c source='human.c' object='human.o' libtool=no \ depfile='.deps/human.Po' tmpdepfile='.deps/human.TPo' \ depmode=gcc /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl -I/sw/bootstrap/include \ -g -O2 -c `test -f human.c || echo './'`human.c source='modechange.c' object='modechange.o' libtool=no \ depfile='.deps/modechange.Po' tmpdepfile='.deps/modechange.TPo' \ depmode=gcc /bin/sh ../depcomp \ ... (A very long time passes go have dinner!) ... BOOTSTRAP DONE. Cleaning up. rm -rf /sw/bootstrap dpkg-scanpackages dists/local/main/binary-darwin-powerpc override | gzip >dists/local/main/binary-darwin-powerpc/Packages.gz ... dpkg-scanpackages dists/local/bootstrap/binary-darwin-powerpc override | gzip >dists/local/bootstrap/binary-darwin-powerpc/Packages.gz Wrote 14 entries to output Packages file. You should now have a working Fink installation in '/sw'. You still need package descriptions if you want to compile packages yourself. You can get them from CVS or by installing the packages.tar.gz tarball. Run 'source /sw/bin/init.csh ; rehash' to set up this Terminal's environment to use Fink. To make the software installed by Fink available in all of your shells, add 'source /sw/bin/init.csh' to the init script '.cshrc' in your home directory. Enjoy.
Now you almost have a working copy of the fink software installation system. The first thing to do when the prompt returns is to edit the file /sw/etc/fink.conf and change the line that reads Trees: local/main stable/main stable/crypto local/bootstrap to Trees: local/main stable/main stable/crypto local/bootstrap unstable/main unstable/crypto
The next thing to do is make that recommended change to your .bashrc or .cshrc file (add . /sw/bin/init.sh or source /sw/bin/init.csh to the bottom of the appropriate shell startup file or watch to see what fink recommends as it finishes its run this syntax changes occasionally), and at the command line execute the file to load its configuration into your running shell (. /sw/bin/init.sh or source /sw/bin/init.csh ; rehash, as appropriate).
Now you need to tell fink to update portions of itself using the software it just constructed in the bootstrap phase. (Again, tcsh syntax is used here because we can't stand bash as a user shell. If you're running bash, use . /sw/bin/init.sh, and ignore the rehash command.) brezup:ray fink $ source /sw/bin/init.csh ; rehash brezup:ray fink $ sudo fink selfupdate-cvs The selfupdate function can track point releases or it can set up your Fink installation to update package descriptions from CVS. Updating from CVS has the advantage that it is more up to date than the last point release. On the other hand, the point release may be more mature or have less bugs. Nevertheless, CVS is recommended. Do you want to set up direct CVS updating? [Y/n] Y Fink has the capability to run the CVS commands as a normal user. That has some advantages - it uses that user's CVS settings files and allows the package descriptions to be edited and updated without becoming root Please specify the user login name that should be used: [root] root For Fink developers only: Enter your SourceForge login name to set up full CVS access. Other users, just press return to set up anonymous read-only access. [anonymous] anonymous mkdir -p /sw/fink.tmp Checking to see if we can use hard links to merge the existing tree. Please ignore errors on the next few lines. touch /sw/fink/README; ln /sw/fink/README /sw/fink.tmp/README Now logging into the CVS server. When CVS asks you for a password, just press return (i.e. the password is empty). cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/fink login (Logging in to anonymous@cvs.sourceforge.net) CVS password: Now downloading package descriptions... cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/fink checkout -d fink dists cvs server: Updating fink U fink/.cvsignore U fink/ChangeLog ... pkg apt-shlibs version ### pkg apt-shlibs version 0.5.4-5 pkg storable-pm version ### pkg storable-pm version 1.0.14-1 No packages to install. The core packages have been updated. You should now update the other packages using commands like 'fink update-all'. brezup:ray fink $ When this step finishes, you're ready to start using fink to install software. fink is also done with the finkcvs directory (it's the source and build directory for the fink command and related software, not for the software fink installs), so you can delete it now as well. All other installing, configuring, and updating is carried out in the /sw directory (or another location that you specified instead). You have a choice of using fink to carry out software installations directly from the command line or from a menu-driven interface to the fink system. These options differ in a fundamental way: The command-line version uses the fink system to download and compile source directly on your computer, whereas the menu-driven system downloads precompiled binaries and installs them. There are advantages and disadvantages to each approach. A precompiled binary is usually quicker to download and install, but it might be out of phase with the software on your system, and you could be stuck waiting for someone else to submit a compiled version before you can download something that works on your system. Using fink to compile, on the other hand, is generally slower, and you run a different but similarly annoying risk of the compilation parameters supplied by fink not being in sync with the compilers and libraries available on your machine. The maintainers of fink packages do a wonderful job of making installation via compilation simple and painless, but regardless of how carefully they try, there are always going to be machines configured by users who "think just a little more differently" than the fink maintainers anticipated in their installer scripts.
|
< Day Day Up > |