Don't worry, compiling is fun and easy. Really, it is.....some of the time, though I admit that some other times it's a pain in the neck.
So what do you need to compile from source on YDL?
1. You need to have installed the Software development packages during installation or by using pirut, but it's very easy to add them with yum:
- Code: Select all
yum groupinstall 'Development Tools'
2. You need to setup your build environment properly so it doesn't mess stuff up, that's actually quite easy
2.1: First, edit /etc/ld.so.conf to look like this:
- Code: Select all
/usr/local/lib
/usr/local/include
/usr/lib/
/usr/include
include ld.so.conf.d/*.conf
2.2 Add this line to /etc/profile
- Code: Select all
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig
2.3 That sets up the build environment and only needs to be done once.
3. Now that the build environment is set up, you can now download all the tarballs you want. What's a tarball? The archive format source code usually comes in. Then you need to know what to do with them once you have them.
3.1 Most of us have a specific spot to put our source tarballs in. I happen to like /usr/src, though probably /usr/local/src would be more "correct"
3.2 Guess what, you get to start using the terminal.... a lot. Compiles are run in the terminal and this is where I usually become root, though only the install step requires being root. So open up your term and move your tarball from where it currently is, usually your /home/user directory to where you want it
- Code: Select all
mv tarball desired_location
3.3 Then change to the directory with your lovely tarball, which for me is /usr/src
- Code: Select all
cd /usr/src
3.4 There are basically two kinds of source tarballs, those that are gzip compressed and those that are bzip compressed. You can tell the difference by looking at the suffixes. gzipped tarballs will have gz or tgz suffixes while bzipped ones will have bz or something similar. Bzip is a more efficient compression algorithm so they're a bit smaller.
3.5 Then you get to untar them, turning those nice tarball archives into directories of source code. Since bzip and gzip are different compression methods, you untar them slightly differently.
gzip ones you do:
- Code: Select all
tar -xvzf name_of_tarball
bzip ones you do:
- Code: Select all
tar -xvjf name_of_tarball
3.6 Then your term spits out a ton of text while it creates your new source directory.
4. Now you have a nice shiny source directory, change into it:
- Code: Select all
cd name_of_source_directory
4.1 You can take a look at what's in there with:
- Code: Select all
ls
Go ahead, it's fun, I always do it.
4.2 Now you can read the README's and INSTALL info. But people often don't, even I don't some of the time, but I should because sometimes there's specific compile and install instructions that should be followed. I like using less, because less is better than more. Heh.
- Code: Select all
less name_of_text_file
You exit out of less by hitting q
4.3 Those readme's and whatnot might tell you what you need to compile your source, additional libraries, optional stuff, etc. But if you're ready, you can go ahead and do the first part of the compile step, configure. That sets up the source for the actual compile, it figures out what libs you have, what compiler you're using what options to use, all sorts of stuff that I don't understand the half of what it means, but it's fun to watch it happening. You do it by:
- Code: Select all
./configure
Though you can check out various configure options that you might want to use by:
- Code: Select all
./configure --help
You use those options by using arguments with ./configure
- Code: Select all
./configure --with-evil --without-sample-function
Why do we use the ./? Because that insures we run the configure script in the directory we're in, not some other directory in our PATH
4.4 Hopefully configure finishes without error messages. If it errors out you get to figure out what went wrong. Usually it's a missing library dependency, requiring either an install of a devel package or a compile of the missing library if it's not in the repos, or not having a new enough library installed. Usually you can slap any error messsages into Google to figure out what you need to do.
4.5 If the configure finished error free, it creates Makefiles and other files too. Makefiles tell make how to "make" the source code into the binary you want. Compiler flags, what libs and headers to include, etc. To run the make, all you do is:
- Code: Select all
make
You terminal will begin spitting out tons of output that will look something like:
- Code: Select all
gcc -02 blah blah blah blah source.c
That is good. What is bad is if you see something like
- Code: Select all
make[2]: *** [all] Error 2
and then see the make quit.
Then you would get to figure out why the compile failed, which usually means slapping error messages into Google. But hopefully the make finishes without errors, which leads to:
4.6 The install step. All make does is make your binary, it doesn't install it. That requires an extra step. This step requires being root.
- Code: Select all
make install
Yep, it's that simple. Your terminal will spit out more lines of stuff, showing where it's putting everything. Usually, the binaries will end up in /usr/local/bin
4.7 There's one more step, which is also done as root. Applications often install libraries, as do libraries when you install them. But your applications need to be able to find them, so now we get to tell the linker, ld, where they are, which is:
- Code: Select all
ldconfig
Always ldconfig after installs, it'll save you frustration of forgetting to and then not having an application run properly when you try to run it.
5. Now your done and can run your application, or compile some more. Enjoy
Ron Rogers Jr. (CronoCloud)