pcbypaul pc software, repair
return to     Homepage
Scripts 'N Tips Xterm Use Firefox Updating update Java Firefox Keys Themes offline Start Firefox Kill Firefox Firefox 16x16 Firefox Problems Compiling Compile wxPython Disk Usage CD Player cdArray Find-Installed Backgrounds Gimp Splash Links LinuxPackages IceWalkers Freshmeat Linux Today Slashdot Compiling from Source Code Overview   These are "generic" Linux compilation instructions -- with some additional notes for Slackware users. Reasons for compiling source code: No precompiled (binary) version of the software you want is available for your system. You want to optimize the software for your system You cannot get a binary to work, perhaps because you are missing a dependency, but you are not sure what it is you need. By trying to compile, the error messages will likely tell you what is missing. The binary may also have used a different version of the compiler, not compatable with your system.   To optimize you should peruse the README file that usually accompanies the source code. Also, for great optimization details, see the configure section below.   As a prerequisite for compiling your own source code, you need to have, of all things, a compiler. For Linux apps written in C, most common, you will almost invariably use the Gnu C compiler (gcc). Some other tools are also usually necessary, such as "make", "bin-utils", etc... but unless you have a real stripped-down or mini-distribution, these tools will already be installed on your machine. In other words, the instructions below will very likely work without any setup on your part. Steps to compile Get the Source   The best place to get the source will be at the homepage for the project. If what you are looking for is to satisfy a dependency, the parent project will likely point you to the page you need. If not, doing a quick search on Google with the project name and "homepage" will often get it. A search on Sourceforge will also often get you where you need to go, because a large percentage of projects are "sponsored" on Sourceforge.   What you will download will likely be a compressed file, a .gz or a more highly-compressed .bz2.

• Unpack it

    Note, if you are using a machine preloaded by me you can ignore what is below because Rox is set up to use "Archive" to uncompress these files for you. You just left-click on the file and it will show a popup box asking where you want to save the expanded files.
  
  Others generally use tar to unpack these files. Open an xterm and change to the location you downloaded the file to... (for example, if you downloaded to "/usr/src", then in the xterm type "cd /usr/src".)
  Next --
  For a .gz use:
  tar -xvzf filename.tar.gz
  For a .bz2 use:
  tar -xvjf filename.tar.bz2
  
  The above will give you a directory with the name of the expanded file, containing the source "tree." cd into that and you are ready for the nitty-gritty. The process consists of the famous "./configure", "make", "make install" -- but what follows are the details.

  
  
• configure

    ...but before you do you should read the README or the install files. I know it smacks of reading the instruction manual to something you just bought, but it really can make a difference. You might find out about support files, there may be some non-standard way of building the program, and you might find out about some ways to optimize the project for your machine.
    Along the same lines, I almost always run something else before I run ./configure, and that is ./configure --help | more. This command will not actually configure the code, but will detail many ways the code CAN be configured. (Where to install, what functions of the software to include or not, among other things.) I find it indispensable.   If you do not choose to alter the basic configuration the command you will enter is simply:
  
  ./configure

  
  
• make

    This actually compiles the code. Compiling can take quite some time, but here is one reason it is often worth the time and trouble . . .  if the build fails, you will see why. This is also true in the above "./configure". Actually, during configuration the output for a failure is easier to read, such as "missing dependency". After the "make" command a failure will generally give you an "error 1", because something did not work. Read the errors and you can find out what failed, often the failure is cause to replace another package that was not configured properly for your system.
  
    The more you compile yourself, the less frequently this happens. It is pleasant to "make" without seeing an error. (BTW: you will almost certainly see "warnings" while make is running. This is to be expected. It is the compiler complaining to the programmer that they did not adhere to the strictest implimentation of the rules, like when and how to properly declare a variable. Or that some function or syntax they are using may soon become obsolete. These warning won't mean anything to you unless you are doing the actual programming. In other words, don't worry about the warnings, just the errors.)
  
  make
  
    When "make" is done the appllication or library is compiled. Now you just have to install it.



• make install or checkinstall

    if you are not root then it is : su type in the root password, then
  
  make install
  
    I have a confession to make -- I am always logged in as root when I compile software. You are not supposed to run your machine as root for security reasons and because, sooner or later, you will mess things up accidentally. But I do anyway, when compiling. I often have to look around the system for stuff, creating extra symlinks and rebuilding quickly with "makepkg" -- and running as root speeds things up for me a lot.
    There -- I got that off my chest.
  
  Slackware Users . . .
    The "makepkg" I mentioned above is a Slackware utility. You should surely find out more about that later, if you run a Slack-based distro. But of immediate importance is the utility "checkinstall" If you have it, you should use it instead of make install. Among other things, you can later uninstall the software with removepkg very easily.
   

  
  


• postinstall notes

    If you ran "checkinstall" you can browse to the folder: /var/log/packages and look for the package you just compiled. The file with the package name is text, and tells you everything that was just installed. To run the program (if a program it was, as opposed to a library or daemon) open an xterm and type in the name of the executable. This will run the program for you and, if it does not run, it will tell you why. Very important.   "checkinstall" users may also copy the new filename.tgz from the source directory they were just compiling in to a safe place. If you ever need to install it again, you can just use that package, rather than compiling all over again. (Unless, of course, you have make changes to your system in the meantime that will affect the build.)
    Well, that's it. Get busy
   
   

  
  

Pages created and served by Linux	Graphics made/edited by the Gimp