Your SlideShare is downloading. ×
Installing Software, Part 3: Command Line
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Installing Software, Part 3: Command Line

2,033

Published on

This last part in the series looks at command line tools for installing Linux software, such as installing from source code.

This last part in the series looks at command line tools for installing Linux software, such as installing from source code.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,033
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Installing Software Part 3 Kevin B. O'Brien Washtenaw Linux Users Group http://www.lugwash.org
  • 2. Previous Presentations ● In the first presentation we focused on GUI package managers, which are mostly just front- ends for mid-level package managers ● This also included a detailed look at repositories ● In the second presentation we looked at command-line package management tools ● These included tools for working with repositories and Washtenaw Linux Users Groupisolated packages for installing 2
  • 3. This Presentation ● For this presentation we will look at installing software when you don't have a package ● This will all be command line techniques ● As before, anything to do with installing software is an Administrative task, so you need to either be logged in as root, or prefix your commands with “sudo” Washtenaw Linux Users Group 3
  • 4. Why Install These Ways? ● The main reason for looking at these methods of installing is that the repositories do not contain the software you are looking to install ● It may be a small, specialized program that never got into anyone's repository ● It may be a newer version that is not in the repositories yet – e.g. Firefox 3.5 is not yet (as of August 2009) in the Ubuntu repositories, and probably won't be until the next release in Linux Users Group Washtenaw October 2009 4
  • 5. Binaries vs. Source ● All software starts out as Source Code ● This is code that is written in a programming language, like C, C++, Java, etc. ● While arcane, it is human-readable if you have developed the skill ● It is not machine-readable, though Washtenaw Linux Users Group 5
  • 6. Source to Binary ● Machines (computers) can only read code that is in zeros and ones ● This is called Binary code ● It is not human-readable ● A software program called a Compiler takes the source code and turns it into Binary code that a computer can read and execute Washtenaw Linux Users Group 6
  • 7. Compilers ● Even before Linux existed, one of the first programs written for the Free Software world was a compiler ● Richard M. Stallman, the founder of the GNU project, created what is called the GNU Compiler Collection, or gcc ● This continues to be developed and improved Washtenaw Linux Users Group 7
  • 8. Compiling programs ● Compiling transforms source code into binary code ● The source code can be in many possible programming languages, so you need to have compilers for each programming language ● Computers can have many possible architectures (i386, 64-bit, RISC, ARM, etc.) ● Covering all of these possibilities is why we call gcc a collection of compilers, not just a single compiler Washtenaw Linux Users Group 8
  • 9. Pre-compiled binaries ● When a compiler has turned source code into binary code, the resulting file is called a binary ● Packages contain binary files, along with some text files for configuration ● But when there is no package, sometimes you can find a binary that has already been compiled for you ● These most commonly have a file extension of *.bin Washtenaw Linux Users Group 9
  • 10. *.bin Files ● The first thing to understand is that Linux does not let any file be executed without specific permission to do so ● Unlike Windows, you cannot just download any old file off the Internet and run it ● You must first, either as root or using sudo, make the file executable ● This is done with the command chmod +x <filename> Group Washtenaw Linux Users 10
  • 11. chmod ● This is short for Change MODe ● The mode, in this case, includes the permissions for what a file is allowed to do ● The “+x” specifies that you are letting it be executable ● So this command lets you take a binary file that you have downloaded, and set it to be executable Washtenaw Linux Users Group 11
  • 12. Installing ● Once the file is executed, you install the file with this command ./<filename> ● That is just a period, a slash, and then the name of the file, and Bob's your uncle! Washtenaw Linux Users Group 12
  • 13. Installing From Shell Scripts ● Sometimes you will have a program distributed as a shell script ● These are files with an extension of *.sh ● But in all respects the installation is the same as with *.bin files ● First, make the script executable using chmod +x <filename> ● Then execute it using ./<filename> Washtenaw Linux Users Group 13
  • 14. Is it really this easy? ● Most of the time it is ● But if you have a problem you may need to check a user forum or web site to get additional help Washtenaw Linux Users Group 14
  • 15. Compiling Programs ● The term “Open Source” comes from the requirement in GPL and similar licenses that the source code of a program must be available in a reasonable way to end users ● Some of those users may be programmers who will modify the code in some way to fit their needs ● But most of us don't know which end of C++ is used to drive screws, and which to pound nails Washtenaw Linux Users Group 15
  • 16. But many of us do it ● Still, compiling is something many of us do more often than we may know ● For example, kernel modules have to be re-compiled whenever the kernel changes, which happens about once a month these days ● Example: VirtualBox ● VirtualBox has a program the recompiles the kernel module, and after a kernel update you will get an error message telling you to run this program when you try to run VirtualBox Users Group Washtenaw Linux 16
  • 17. Isn't it hard? ● Actually, not really ● By definition, any Open source program must make the source code available ● You can download the source code yourself and compile it yourself ● It may even work better for you than a pre-compiled binary Washtenaw Linux Users Group 17
  • 18. Benefits of compiling ● Possibly a minor one for many people, but compiling your software can teach you a lot about how your computer works ● The biggest benefit is that the compiled program is tuned for your system, your CPU, your version of Linux, etc. ● You can even (this is optional) go into the source code and really tune it up before compiling Washtenaw Linux Users Group 18
  • 19. Reasons not to compile ● You must do all of the things a package manager would do for you otherwise – You need to resolve all of the dependencies – You need to look for and install any bug fixes, updates, etc. as needed – If you change your mind, you need to manually uninstall Washtenaw Linux Users Group 19
  • 20. Pre-requisites ● Before you start, make sure you have everything you need ● This can vary by distribution in terms of what is installed by default, and what needs to be added by you ● For example, in Ubuntu and its derivatives (Kubuntu, Xubuntu) you need to install a package called build-essential to have all of the software neededWashtenaw Linux Users Group install to compile and 20
  • 21. Pre-requisites 2 ● In general here are some things you need to have installed if your distro does not have a neat package like Ubuntu does – Headers for the Linux Kernel – Gcc – make Washtenaw Linux Users Group 21
  • 22. Get the Source Code ● The first step to compiling and installing a program is to get the source code ● Remember, if it is an Open Source program they must make it available ● You may have two options: – A Source Archive – good for home users – A CVS system of some kind – intended for developers (e.g. SVN, GIT) Washtenaw Linux Users Group 22
  • 23. Firefox Source Code ● You can go to the Firefox site https://developer.mozilla.org/en/download_moz illa_source_code and see how they do it ● For developers, they use a CVS called Mercurial ● For the rest of us, they provide “tarballs”, which is the format we will cover shortly ● These are provided on an ftp server Washtenaw Linux Users Group 23
  • 24. Temporary working directory ● You can use a temporary working directory for these activities ● For example you can use the ~/tmp directory ● This is the equivalent of /home/username/tmp ● However, there is a good reason to keep your build directory after the install ● So I would suggest using something other than the ~/tmp directory. Maybe something like ~/builds that you create in your home directory Washtenaw Linux Users Group 24
  • 25. Source Archives (tarballs) ● Source code is always contained in text files ● But it is not usually a single file ● Most of the time it is a collection of files ● These are put into what are called Archives, which have an extension *.tar (Tape ARchive), a name which comes from the days of tape backup systems ● These files are then compressed to save on bandwidth Washtenaw Linux Users Group 25
  • 26. Compression of Archives ● These files are usually compressed with either gzip or bzip2 ● The extensions then become *.tar.gz, or *.tar.bz2 ● Uncompressing is then a simple matter of using cd to go to the directory the file is in (e.g. ~/builds), and then – tar -zxpf appname.tar.gz – tar -jzpf appname.tar.bz2 Washtenaw Linux Users Group 26
  • 27. Dependencies ● This is a potential problem with compiling from tarballs ● Sometimes the developer will tell you up front what the dependencies are ● Otherwise, you will get errors when you try to compile ● This is often the hardest part of the process, but not at all impossible to do Washtenaw Linux Users Group 27
  • 28. Three-Step Dance ● Compiling and installing software involves a Three-Step Dance – Configure – Make – Make Install Washtenaw Linux Users Group 28
  • 29. Configure 1 ● This is where the dependencies will come up ● This is also where you can select some settings you want to use ● When you run this, you are running a script called “configure” that is part of the collection you downloaded in the tarball ● In this script, the programmer(s) will do several things Washtenaw Linux Users Group 29
  • 30. Configure 2 ● First, they will check for the required “helper” programs (dependencies) they need to have to run this program ● If they do not find them, they will give an error ● If this is because the program is not on your system, you need to install it ● Sometimes it is on your system, but not where the script expects it to be. You should be able to tell it the path to find the program in that case. Washtenaw Linux Users Group 30
  • 31. Configure 3 ● This script will also have options of various kinds ● For instance, certain features of the program may require a dependency. In this case, if you do not need this feature(s), you can ignore it ● You may be able to specify a non-standard install location ● You may have the option to disable features you don't need that might make the program run more slowly Washtenaw Linux Users Group 31
  • 32. Options ● The point about options is that they are optional ● You can safely ignore options ● A good rule of thumb is that if you are not sure what the option is asking you, leave it alone ● Remember, if the program really needs something, it won't let you get any further until you take care of it Washtenaw Linux Users Group 32
  • 33. More on Options ● Optional features will generally be presented in a format like --disable-<feature> --enable-<feature> ● Optional packages will generally be presented in a format like --with-<packagename><other options> – Often these package option lines will have (default:test) at the end of the line. This tells the script Linux check and see if you 33 Washtenaw to Users Group have this package installed
  • 34. Install Location ● The option that tells the script where to install is the --prefix option ● Normally compiled software will go in the /usr/local directory tree – Executables go in /usr/local/bin – Libraries go in /usr/local/lib ● Some applications (e.g. kde apps) need to be installed in a different location Washtenaw Linux Users Group 34
  • 35. Example 1 ● cd into the directory ~/builds/<programname> and run ./configure --prefix=/usr –disable- <option> ● This will run the configure script for this program, set the install directory to /usr (instead of /usr/local), and disable the option selected Washtenaw Linux Users Group 35
  • 36. Example 2 ● You should get output that looks something like $ checking build system type... i686-pc-linux-gnu $ checking host system type...i686- pc-linux-gnu $ checking whether build environment is sane... yes and so on ● If you are missing aLinux Users Group dependency you will Washtenaw 36 get a warning that says that the program requires some other program or library
  • 37. More on Dependencies ● Often what is needed here is something called a development package ● You may already have the base package installed, but what is needed is the associated development package ● For example, Ubuntu uses the Gnome desktop by default, and so gtk is certainly installed. But you may not have libgtk2.0-dev installed, and that is what Washtenaw Linux Users Group needs your program 37
  • 38. Step One: configure ● So, once you have understood about dependencies, and you have the necessary compilers nad utilities installed, you are ready to do step one: configure ● I will assume you are in a directory like ~/builds/<packagename>, in which you have the source code you downloaded (and unzipped/extracted) ● In this directory Washtenaw Linux Users Group type ./configure 38
  • 39. Configure 2 ● If you get errors, such as unsatisfied dependencies, you will need to first install those dependencies ● Then try it again ● Wash, rinse, repeat, until you no longer get any errors ● That should mean you have now successfully done your configure Washtenaw Linux Users Group 39
  • 40. The Makefile ● The output of a successful configure is a makefile ● This file contains all of the instructions for successfully compiling a binary ● Once you have a makefile, the hard part of compiling from source is over. You should now have resolved any dependency issues. Washtenaw Linux Users Group 40
  • 41. Step Two: make ● At this point, you are ready for the second step of the three-step dance ● In the same directory that you were in to create your makefile, run the make command make ● The most common problem at this point would be an error that says it cannot find a makefile ● This means the firstLinux Users Group Washtenaw step, configure, did not 41 successfully complete, so go back to step one
  • 42. Make 2 ● You can watch the output of the make command, but it is not necessary ● It will generate output as each source code file is processed ● This can take seconds, minutes, or longer, depending on the amount of source code being processed ● I'd just get a cup of coffee Washtenaw Linux Users Group 42
  • 43. Checking your make ● Some open source projects have their own test suite ● You can try this to see if your make is correct make check ● This step is optional, but it is a good idea ● If you discover that a feature of the program did not make correctly, but it is one you never want to use, you can ignore the error Washtenaw Linux Users Group 43
  • 44. Step Three: make install ● Once the make command has finished, you are ready to take step three: make install ● You absolutely must be root or use sudo here ● Example: sudo make install ● This will install the compiled binary in the location you specified in the configure step Washtenaw Linux Users Group 44
  • 45. Uninstall ● If you change your mind, or for any reason you need to remove the program, go back into your build directory (e.g. ~/builds/<programname>) and run (as root, or using sudo) sudo make uninstall ● This is why I recommended a separate builds directory, instead of the ~/tmp directory often seen in how-tos ● I nevere put things I want to keep in a temporary directory Linux Users Group Washtenaw 45
  • 46. Running the program ● Usually you can run the program you just installed by typing the name of the program and pressing enter ● If you get an error that no such file or program could be found, that may mean you installed it into a non-standard location ● In that case, you need to add the location to your path Washtenaw Linux Users Group 46
  • 47. Path ● The PATH is defined for each user in the /etc/profile file ● Edit this with a text editor and add the location of your program Washtenaw Linux Users Group 47

×