In fact this is not an installation in the sense you would expect on a Windows system. Here is some context to make you understand better what you attempt to do:

Software is written in source code (the programs text, written by the programmer) and then translated into the code the machine is able to understand ("binary"). The programs which do this translation are called "compilers". Most compilers have an awful lot of configuration options, which is why compiling a complete software package is an awful lof commands. To make this easier there is (standardized) tool in all UNIX systems, which is called "make". "make" is rule-based and although it was developed with compiling programs in mind it can be used for other things (like installing software) too.

Having said this: what you do with "configure" is calling a special script (called "configure", which is a quasi-standard) which attempts to best-guess the special surroundings it operates in and then makes adjustments to the rule-files "make" will operate on in the second step. Have a look at a file called "Makefile" in the directory you unpacked your source code to to see it.

"Make" called without anything compiles the program from the source and if it is successful it will be called in the form "make install", which will, instead of compiling the software, install it on the computer.

Yes. instead of the last line you might want to enter the commands separately:

Code:

./configure
make
make install

and watch its output. You do not need to invoke "command" as long as you do it from the command line, which i suggest you do.

Yes. Maybe the dependencies ahve dependencies itself, so you might have to do that several times, but basically you are correct.


UNIX-systems follow a general plan where certain files should go. This is not a standard and there are minor deviations from one system to the other, but in general all UNIX-like systems follow this plan. See the "file systems hierarchy standard", which tries to lay down this standard for Linux systems. More than 95% of what is in there is correct for any other system too, even if there is no "law" compelling someone to do it this way.

"/usr/bin" is the place where system binaries go and you should NOT put your programs there. You "might" put a softlink there pointing at your binary, but thats about all. I'd recommend refraining even from that.

"/usr/local/bin" is the place where you can put things, but you should only put administrative binaries there. If you write a script for trimming log files or creating user accounts and similar things this is the place to put these. Application programs should get a separate directory in "/opt" and a binary (better yet: a link to the binary) in "/opt/bin". Read the aforementioned FHS-document and you will understand what i talk about.

A UNIX system has only one user account which really is allowed to do everything - "root". One should NOT work as root if it is not absolutely necessary. To compile a program can without problems be done as ordinary user. Only to install the program (which is a change to the system) one needs the user "root" and its special power and therefore you switch the effective user for this one command. For this you prepend it by "sudo", which is a software package to do this. Find out more about the "sudo" software by reading its man page or searching the net.

No. Unix (MacOS is a UNIX with some graphical gimmicks on top) systems are "source-compatible", not "binary-compatible" like Windows. If a software runs on a Windows machine you can copy it (its binary, the "*.exe" file), put it on another Windws system and it will run there too. Because UNIX runs on a wide range of hardware with different processors, different bus systems, etc.., it is "source-compatible". If you write a software text and it compiles and runs on one system you can take the program text (notice: the text, not the binary!), transfer it to another UNIX system, compile it there and the resulting binary will run there (ahem: in theory :-)) ). But because the processors on the two systems might be different and therefore the binaries will be different even if they come from the same program source.

I hope this helps.

bakunin