Compiling applications from source

[kfranc9]

Hey you guys, I consider myself an intermediate computer user (compared to the gurus around here that make me feel small sometimes), but I am farely new to Linux. I can yum and apt all day but i have no idea how to compile from source nor have I found a guide that gives me the ins and outs of completing this task. Please point me in the right direction.

 

[Nothinman]

It depends on the project, most come with an INSTALL file with directions on what you need to do to compile them. The hardest part is making sure you have all of the right dependencies installed since you'll need to install all of the required -dev packages on top of the normal ones to build against them. This is especially frustrating when the build system sucks and doesn't give nice error messages and all you've got to help you figure out what's missing is the name of an include file or function name that gcc's complaining about not finding.

 

[esun]

The reason there isn't a HOWTO or book on this topic is because it's different for every project. That's why package managers are so convenient. If it's not available via a package manager, you have to rely on the project's documentation.

 

[Alone]

Most things a newb would consider compiling from source have packages already available. If you're working on SVN packages or something else in trial period, why bother? If you want to learn for the sake of learning (and being ready when you get more familiar), then just look at the contents of the folder.

Generally, as Nothinman said, there's an install file. So, assuming it's done the normal way:

./configure
make && make install

Make install needs to be run as root/super user, so:

./configure
make && sudo make install

But, yeah, you'll need the dependencies. These can normally be satisfied with this, simply:

sudo apt-get install build-essential

That is, assuming you're using a debian based distribution.

But you'll want to look for a list of deps. If you try to configure & make without the required deps, it'll tell you which ones you're missing.

 

[Nothinman]

But, yeah, you'll need the dependencies. These can normally be satisfied with this, simply:

No, that'll get you a complier but that's about it. For example, if you're building a Gnome app you'll need at least gnome-core-devel (which is a pseudo-package that depends on like 30 different -dev packages) and maybe more depending on what the app actually does.

 

[Alone]

Originally posted by: Nothinman

But, yeah, you'll need the dependencies. These can normally be satisfied with this, simply:

No, that'll get you a complier but that's about it. For example, if you're building a Gnome app you'll need at least gnome-core-devel (which is a pseudo-package that depends on like 30 different -dev packages) and maybe more depending on what the app actually does.

I'm strictly talking about the basic dependencies, if you're compiling something else, for example, beryl, you'll need other dev files specifically related to it. I've compiled a few programs without installing other deps except what build-essential gives me.

 

[Nothinman]

I've compiled a few programs without installing other deps except what build-essential gives me.

I don't doubt it but they must have been extremely simple because all build-essential gets you is gcc and the standard C library.

 

[Alone]

Originally posted by: Nothinman

I've compiled a few programs without installing other deps except what build-essential gives me.

I don't doubt it but they must have been extremely simple because all build-essential gets you is gcc and the standard C library.

You'll have to forgive me. I often use the wrong terms. I said dependencies but I meant dependencies for compiling in general (not the deps of what you're compiling). There was probably a better word for it (build-essentials? ).

 

[Nothinman]

build-essential is a pseudo-package in Debian and Ubuntu that depends on gcc, make and the standard C library headers.

 

[kfranc9]

This article has been helpful but I'm not sure what really has been the challenge for me. I think having a source that you know is reputable can push a n3wb (such as myself) to troubleshoot further when he's running into dependency hell! A problem this how-to has is it only tells you how to extract tar.gz source files when it should also mention other compression types. It might even talk about how some applications are developed for a particular X window systems as well...

http://digg.com/programming/Ho...tware_from_Source_Code

 

[Fallen Kell]

As others have said, most packages from source will include a "INSTALL.TXT", or a "README"/"README.TXT", or "PLATFORM.TXT", or something similar. These files or group of files will contain the information on how to setup and build the package. If no such documentation exists, then it is either an extremely experimental/beta version and/or not supported in anyway, shape or form. Typically the download will include a "configure" script which will scan through your system and run checks to see that you have everything that is needed installed (if it can find it), and lets you set your install options (like install location, extra build options, shared library build or static build (a static build will include all needed library files in the actual executable, the shared library build will use the external libraries on the system to run the program... there are some cases where you may want one option or the other depending on what you are doing, for instance, you may be sharing the application out across the network where not every system has the same versions of certain library files, so you may want to do a static build in this case...). The "./configure" script will usually list all the options that you can set on the program before you compile it, and you tell the "./configure" script the options with different flags. "./configure --prefix=/sw/local/my_app --enable-ftp --with-zlib=/usr/local/lib --without-gettext" for example is a how you might turn on or off certain options as well as tell the script where something is located (like where the zlib libraries are found in /usr/local/lib) and where you want the application to install (--prefix=/sw/local/my_app).

The configure scrip creates the custom built "Makefile". You then use the "make" command (which defaults to look for a file called "Makefile"), and it will start to build the object files from the source code. Once the object files are created, "make install" will merge all the object files into the correct binaries and copy the binaries to the install directory. However, most complex software will include a group of tests to make sure your build is working properly and found everything it needed. To run the test, it is usually "make test". You do this before you do the "make install". If something is wrong with the test (i.e. it fails a lot of the tests), run a "make distclean" which will remove all the object files created from the initial "make" and remove the Makefile (since we know something is wrong with that setup) and then you can try again, hopefully using the information from the errors to diagnose the reason for the problem and correcting it by changing a config option, installing a new library file, changing your archiver tool, or loader tool, or even compiler.

Please note, that building a program is not always easy and straight-forward. That is why people get college degree's in Computer Science to learn what to do. Ask anyone who has tried to compile the latest version of gcc, or Xorg, or XFree86, and they will tell you it can be a biggest pain in the neck.

 

[cleverhandle]

I don't think it's been mentioned yet, but if the package is built using autotools (uses configure, make, etc.), you can always get a list of available options by doing

./configure --help

That will spit out a list of all the options you can give to configure. Generally speaking, the first couple blocks of options are standard options available to all programs and for which the defaults are usually OK. It's typically the very last block of options that contains anything you might actually want to change like enabling/disabling specific program features.

Also, it's often convenient to keep a record of the build process so you can post snippets online to get help. I do this with commands like

./configure --option1=foo --option2=bar 2>&1 | tee c.out

The "2>&1 | tee c.out" part sends both the standard output and standard error to your screen so you can watch the progress, but also duplicates both to the file "c.out". Then if something bombs out, you can scan the file using less or some other tool. You can do the same thing with any other commands.

Really, "configure, make, make install" is about all you need to know. If a package doesn't follow that pattern then you probably shouldn't try to build it, as mentioned above.

 

[silverpig]

The cheap and easy(?) way to do it is to just install gentoo.


emerge <foo>

will build that package from source

 

[LuckyTaxi]

So if i wanted to uninstall a package that was compiled from source, how would one do that?
I run both freebsd and centos so uninstalling is pretty easy with their respective commands but let's say i download a package off of sourceforge.
it'll install fine but let's say i dont want to have it anymore?

 

[cleverhandle]

Originally posted by: lilcam
So if i wanted to uninstall a package that was compiled from source, how would one do that?

make uninstall should work if the software was properly packaged. But you need the original directory you built from, or at least a duplicate of it with the same configure options. Usually what I do, after installing and testing the software, is run a make clean to get rid of the old object files, then tar up the directory to foo-archive.tgz. That tarball and the original source tarball both live in /usr/local/src.

If make uninstall doesn't work, then you just have to hunt and peck through your directories and remove files manually. But in my experience, most packages that don't include the uninstall option are pretty small-time affairs with no more than a handful of files in the first place.

Overall, the best choice is still to find a native package for your distro, of course. There's really not much out there that isn't included in Debian/Ubuntu.

 

[Nothinman]

The cheap and easy(?) way to do it is to just install gentoo.

Which completely avoids the learning how to compile anything part which what was the OP wanted.

 

[Cogman]

to get the packages in ubunto, I think the easiest way is to apt-get install apt-build then do a apt-build install --reinstall firefox. That should get you all the packages you need to compile most anything. After that is is like everyone else has said you just ./configure && make && make install with most packages. Sometimes you have to autoconf and sometimes you have to just type make. Each package is unique. But the ./configure make method is by far the most common in linux.

 

[xtknight]

Originally posted by: lilcam
So if i wanted to uninstall a package that was compiled from source, how would one do that?
I run both freebsd and centos so uninstalling is pretty easy with their respective commands but let's say i download a package off of sourceforge.
it'll install fine but let's say i dont want to have it anymore?

Then, you can use packaging tools such as dh_make if the compiled program has a debian/ dir. Or you can find a deb from getdeb. "checkinstall" works OK for some apps. I'm perfectly aware the latter two are far from perfect options but if you want to uninstall apps those are your choices apart from doing it manually. This is all assuming there is no "make uninstall", too.