Cross Linux From Scratch

This course will become read-only in the near future. Tell us at community.p2pu.org if that is a problem.

Git [June 15, 2012, 6:17 a.m.]


While you will want a git binary available to you, compiling from source in this section is entirely optional. Depending on how "from scratch" you'd like to be, there are precompiled or pre-packaged versions of git available to just about every operating system. Git hosts downloads here,

http://git-scm.com/downloads

One way or the other, you'll need git working to complete this task.


Windows users only

First, when you install the binary you get from the git website, you'll want to make sure that the "Run git from the Windows Command Prompt" radio button is selected, followed by the "Checkout as-is, commit Unix-style line endings" button on the next screen.

Second, this time, it's you MinGW/MSYS users that catch a break. Go ahead and install a pre-compiled binary for windows from the above URL, and then skip ahead to the next task. You are welcome to try to build git on windows, but I was unsuccessful under MinGW/MSYS. I'm going to use the pre-compiled binary. If you want to try, one thing I had to do was create a config.cache file with the following contents:

git_cv_socklen_t_equiv=int

and then add the configure option,

--cache-file=config.cache

However, my 64 bit windows would still not include winsock2.h correctly. You're also going to need zlib, which you can install using mingw-get.

Otherwise, there is a great development community specifically for porting git to windows, including building it from source, here

http://code.google.com/p/msysgit/

and if you're comfortable trying your luck with cygwin instead of msys (bearing in mind that your git can only be used in your cygwin environment and not your msys environment), there's a tutorial I haven't tried here,

http://techblogging.wordpress.com/2008/04/11/compiling-and-installing-git-on-windows-under-cygwin/

What you can do is read through this section for generic package building instructions, just realize that it's not going to apply directly to you. The git download page I linked earlier has a link to the windows binary, and I've provided a direct link here as well:

https://github.com/downloads/schacon/testy/Git-1.7.10-preview20120409.exe


Everyone else

So if you're still reading this section, you're in a linux, BSD, or mac environment, or you're just here to learn.

 

Feel free to just install git the easy way and skip to the next section if you have any problems here. My rational for building for source here, is to A.) ensure that our build environment works, and b.) give you a gentle walk-through of the unix packaging process. We're going to create what's called a "source controlled package". This section and the troubleshooting section will be a reference tool for you later if you have any problems.

One of the biggest complaints people have building LFS is that it's frustrating when a package doesn't build correctly, and you have to scrap everything and start over. Some people may have joked that it would be a lot easier with a time machine. Well guess what! Git gives us a kind of a "time machine". You can undo and redo operations, create multiple timelines, merge them back together, cherry pick and ressurect anything you've done in the past, and resolve conflicting visions between you and your fellow time travelers, among other things. It has a little bit of a learning curve to use it to its full potential, but we'll only be using very simple commands.

We're going to use the page from the "CBLFS" book to build this package. The "B" stands for "beyond". It's appropriate, then, that we're pulling the instructions for creating our time machine from the future, in the book intended to be used once the Cross Linux From Scratch system has already been built.

Enough talk. Allons-Y!

The CBLFS page for git is here:

http://cblfs.cross-lfs.org/index.php/GIT

By the way, that's also an easy way to look up generic build instructions for any linux package ever; just type in

http://cblfs.cross-lfs.org/index.php/<name_of_package>

The first letter is usually capitalized, and spaces are underscores. If you don't find the package that way (I didn't in this case because GIT is all capitals), just use the search box in the lower left hand corner. If you come across a rare package that isn't up there already, and you figure out how to build and install it, consider making a CBLFS page yourself.


Step 1: Grab Sources

According to the CBLFS book page, the sources are located at

 

http://git-core.googlecode.com/files/git-1.7.8.2.tar.gz

http://git-core.googlecode.com/files/git-manpages-1.7.8.2.tar.gz

We'll go ahead and grab those.

If it feels like I'm talking a little fast at this point, this would be a good place to review the links in the "prerequisites" section. Things are going to get a little technical from here on out.

First, fire up a shell as an ordinary user. We'll want to be an ordinary user for steps 1-5. Then:


cd ~/clfs/sources
wget http://git-core.googlecode.com/files/git-1.7.8.2.tar.gz
wget http://git-core.googlecode.com/files/git-manpages-1.7.8.2.tar.gz

That's going to be step 1 whenever we grab anything from the CBLFS book, by the way; grab all the sources listed at the top of the page, and dump them in our clfs/sources folder.


Step 2: Check Dependencies

Step 2 is going to be looking at the dependencies section. In this case, there's 2 required packages:

 

  • Curl
  • Expat
     

You'll want to use your OS's standard package management tools to get those. If you're reading this and you've been following instructions, you've already got expat. If you want to try your luck building Curl from scratch, here's its CBLFS page:

http://cblfs.cross-lfs.org/index.php/Curl

If you're doing things the hard way (go you!), the build instructions for Curl are going to be nearly identical to the ones for git, so just keep reading. if you need help building packages from source, you can use the second video in the Environment section for help. There, I build the ncurses package from source on windows, but the same general procedure should work for you too.


Step 3: Write a Spec

Once you've got all your dependencies installed, step 3 is to copy the build instructions into a packager script. Since we don't have RPM installed yet, we're going to make a shell script for this. I'm doing things this way in case you decide you'd rather not use RPM, so that you'll have some way of packaging. You can always use shell scripts for packaging no matter what.

 

For this tutorial I'll be building a non-multilib system. As a challenge to yourself, if your processor can handle 64 bit libraries, you can go back and build a multilib system later. Let's go to the git page, highlight all the instructions under "non multilib", and copy them. Then we'll do this in our shell:

cd ~/clfs/specs
cat > git.sh << "EIEIO"
Compile the package:
./configure --prefix=/usr --libexecdir=/usr/lib \
    --sysconfdir=/etc &&
make
Install the package
make install
Install the man pages:
tar xvf ../git-manpages-1.7.8.2.tar.gz -C /usr/share/man
EIEIO

Note that you don't have to type in all of that; everything between the EIEIOs I just pasted in.

Next, let's open that file we just made (it's called "git.sh") in our favorite text editor. My personal favorite is vim. Other good command line choices are emacs, nano, and joe. If you open in a graphical editor, make sure there's no text formatting going on.

#!/bin/bash

set -e

# This should be /usr for bsd, mac, or linux, or /mingw on windows
PREFIX=/usr

#Compile the package:
./configure --prefix=$PREFIX --libexecdir=$PREFIX/lib \
  --sysconfdir=/etc && make

# Install the package
make install

# Install the man pages:
tar xvf ../git-manpages-1.7.8.2.tar.gz -C /usr/share/man

What we did there is:

  • added the line "#!/bin/bash" at the beginning
    • The "#!/bin/bash" line is called the "shebang". It says that when we run the script as an executable, we should use /bin/bash to interpret it. So if this were a python script instead, we'd have something like "#!/usr/bin/python".
       
  • added the line "set -e"
    • "set -e" causes the script to exit immediately if something goes wrong.
       
  • added a few "#" marks at the beginnings of a few lines.
    • These are what are known as "commenting out a line". The bash interpreter, /bin/bash, ignores everything after one of those hash marks. If you look at the git CBLFS page, you'll notice I put one of those marks everywhere the line was a comment not meant to be run, so that only the real commands get executed. I like leaving those in there, because they keep the script real easy to read if I have to make changes later.
       
  • Set up a PREFIX environment variable, and changed --prefix=/usr to --prefix=$PREFIX
    • This is the directory you're installing to. The entire directory tree for git is going to be under this prefix. So binaries will go into $PREFIX/bin, c and c++ headers will go into $PREFIX/include, and libraries will go into $PREFIX/lib. Sometimes packages need other configuration files. Those go into folders called etc, var, and shared. We'll go over those later on when we start build CLFS. I left some suggestions as to what PREFIX should be in the comment I added.
      • ADVANCED: One other suggestion, if you're trying to do everything as an ordinary user, is to change this directory to one you have write permissions on as an ordinary user. Just be sure you know what you're doing. This is a little advanced for this tutorial, but if you go this route, you'll need to set your PATH up so that your binaries are on it, and you'll need to setup your CFLAGS variable to include -I${PREFIX}/include and your LDFLAGS variable to include -L${PREFIX}/include. Those shouldn't be substitutions, by the way; go ahead and expand them because you'll be setting PREFIX to other things.

We're going to need to make one more quick change to that last line. If you recall, our git-manpages tarball is inside our sources directory. We also (probably) don't have permission to install anything as an ordinary user, so we'll just echo the command so that we can copy/paste it into an admin shell later. For quick changes, I like to use the sed tool instead of firing up my editor. We can edit everything like this:

sed -e 's@\.\./git-manpages@~/clfs/sources/git-manpages@' \
    -e 's/^tar.\+/echo "&"/' \
    -e 's/make install/echo "&"/' \
    -i git.sh

The sed tool relies on something called "regular expressions".
You can look those up online if you'd like to learn how to use the sed tool for yourself.

Step 4: Extract The Package 




	Okay. Now that we've prepared our installer script, which I'll call "spec" from now on, it's on to step 4. Step 4 is changing to our build directory and extracting.

 



cd ~/clfs/build
tar xvf ../sources/git-1.7.8.2.tar.gz
cd git-1.7.8.2

Easy, right?


Step 5: Build the Package

Step 5 is the one most likely to give you headaches. So if anything goes wrong, the entire troubleshooting task is dedicated just to step 5 of the build process here.

 

All that buildup, you ready for step 5?

sh ../../specs/git.sh


Step 6: Installation

Step 6, is to install everything we just built. If you were following instructions earlier, you're an ordinary user and don't have the authority to install anything. That's the way we like it in unix-land; if you can't install anything to your OS, you can't screw up your OS. But assuming everything went well in step 5, step 6 starts with you logging in as an administrator. You do that in most unix-like OSes like this:

 

su -

(and in case you're reading these instructions from windows, it's

runas /user:Administrator bash

)

Either way, you'll have to enter your administrator's password. You then do this:

cd /home/you/clfs/build/git-1.7.8.2
make install

And if all goes well, you now have git. Congratulations! To test, run

git --version