InformIT: Mac OS X Unleashed > Common Sense and Configuration Options

Table of Contents

Common Sense and Configuration Options

A reasonable number of problems can be solved by a suitable application of common sense. The biggest problem with this is users appear to have a difficult time figuring out what sense is common, and what is not. Repeatedly, I have seen users who were convinced their problems were the fault of a program or machine, and were hopping mad at the system for treating them poorly. Most frequently, however, it turns out that they've mistyped some command or entered an incorrect parameter, and fixing this also fixes the problem. Conversely, I've seen users who have spent hours fighting with a problem, firmly convinced that they were making some trivial error and were simply incapable of seeing it. Almost to the user, these cases turn out to be actual machine or software errors, rather than user errors. If you're new to the Unix environment, watch for this tendency—if you think something is the system's fault, stop to consider whether you really have done everything properly. If you think you're doing something wrong, but can't figure out what it is after suitable inspection, don't forget that the people who wrote the software are users too, and could have made an error just as easily.

That being said, we'll provide a general list of things that might help you figure out what's going wrong with a piece of compiled software. There is no such thing as a complete list, but these are relatively good places to start.

The absolute first thing to try, if software doesn't install, is reading the instructions. I know, you've already read the instructions. Read them again.

Make certain while reading the instructions that you've read any sections dealing specifically with OS X. If there's nothing that deals specifically with OS X, the instructions for BSD, NextStep, or OpenStep installation might be of interest.
Examine the evidence of a problem. Error messages are generally trying to tell you something beyond the fact that there was an error. They sometimes do an abysmally bad job of it, but the average error message contains at least some clues as to what the error is and how to fix it.
If the error involves something going wrong well after the compile—for example, when the program is running—check whether the program outputs log files. Many programs write progress reports and debugging information into log files. The location of these files is frequently defined in the program's configuration options, but programs can also log via the SYSLOG facility and write log information into files in the /var/log/ directory.
If the program doesn't have a log file, check to see whether it has a debug or verbose mode (usually invoked with -d or —debug and -v or —verbose, respectively). Adding these to the programs invocation will either enable log output to a file, or cause the program to produce useful output to the terminal.
If the problem is that at the compilation step, the program makes a complaint that it can't find a library (typically a file ending in .o or .so), it might be because the compiler doesn't know where to find it, not because it doesn't exist. If you can find the file it's complaining about, you can attempt to fix the problem in one of two ways. The first involves editing the makefile. If you can find where the library is used in the makefile (look for the < filename >.o string in the makefile), you can try adding -L< pathtodirectory > to the makefile. < pathtodirectory > should be the full path to the directory that the library was found in. The second involves informing the compiler of the location in a more general fashion. At the command line, enter setenv LD_LIBRARY_PATH < pathtodirectory >. The LD_LIBRARY_PATH environment variable tells the compiler that there is an additional place for it to check for all libraries. The problem with this approach is it's not convenient to enter every possible library path this way, and you might need to add more than one, depending on how your system is arranged.
A syntax error from the compiler that indicates a line number is a statement that invalid code has been found in the file. This is an indication that there's something wrong with the program, or perhaps that you've downloaded it incorrectly, or that it has become corrupted on your local machine. Something fixable in the syntax is, for example, an edit done in a Mac OS side editor that's been saved with Macintosh end-of-line characters instead of Unix end-of-line characters (or has accumulated an assortment of each through the use of different editors).

File Locations, and Fighting with Installers | Next Section

Previous Section