HOWTO: Compile source code

[pay]

Howto Compile Source Code on Ubuntu

One thing that I have noticed is a lot of new users to Ubuntu have trouble when it comes to compilling source code. Hopefully, after this guide you will see it as the rather simple task that it really is. First thing, make sure that you have the basic compillers, otherwise you won't be able to compile anything. Open up the terminal and type in sudo aptitude install build-essentialA few other tools that can come in usefull are automake1.9, libtoolize, subversion, cvs and checkinstall.

Now we are on to the fun stuff:) I'll use an example of compilling mplayer (gui) with x264, xvid and ffmpeg support. There are a few ways to download the source and compile it so I will show multiple ways to do each section.

Part 1 – Compilling XviD
Firstly, download the source code. There are a few ways to do this.

1) Using apt
apt-get source xvid

2)Browsing the website and extracting it
wget http://downloads.xvid.org/downloads/xvidcore-1.1.2.tar.bz2
tar jxvf xvidcore-1.1.2.tar.bz2(note: for a tar.gz archive use tar zxvf <archive>)

3) Using developer cvs/svn repositories
cvs -d:pserver:anonymous@cvs.xvid.org:/xvid login #(just type enter)
cvs -d:pserver:anonymous@cvs.xvid.org:/xvid co xvidcore

Now make sure that you have all the dependencies needed to compile the code.sudo apt-get build-dep xvidwill download everything you need (Make sure that you have the deb-src repo enabled). If you get errors while configureing about a missing library or package, install that package;)

Secondly, configure the source code. For cvs it is slightly different (for xvid anyway, normally the readme will give clues). For cvs only run ./bootstrap.shbefore ./configure. Now change the directory to where you have extracted the source code tocd ${xvidcore}/build/genericNow the hard part. Picking what options you want to compile the source code with. My recommened way is ./configure CFLAGS="-march=athlon64 -O2 -pipe -mtune=athlon64” CHOST="x86_64-pc-linux-gnu" MAKEOPTS="-j2" –prefix=/usr This ./configure command will result in optimised code, which should be faster but may make debugging almost impossible. Don't open a new bug report unless if you compile it generically (ie ./configure –prefix=/usr). Here's a list of CFLAGS recommened for different processors. http://gentoo-wiki.com/Safe_Cflags
For more information on CFLAGS look here http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Optimize-Options.html

Now Compile the source with makemake

Once that finishes without any errors you will have the program compilled in that directory. You can use it to make sure that it works as expected before installing it. There are a few ways to intall the software. A simplesudo make install will install it as is. Using checkinstall you can make a debian file withsudo checkinstall -D make install
sudo dpkg -i <package>.debAlso you can make a more generic debian file withsudo dpkg-buildpackageHowever, it will just compile a generic package without optimisations. Alsosudo apt-get –build source will make a generic debian package of the source code. Hopefully there is someone that has found this information useful. Recommendations and constructive cristisms are encouraged.

TO BE CONTINUED with x264, ffmpeg with enabling features (xvid and x264 support) and mplayer with a gui and codec support.

[Kossilar]

Well I hate to be the one to say this, and I feel like a total jackass, but this isn't helpful at all. Its much too specific.

It seems like each individual piece of software needs its own configurations at build time. Frankly I need a manual, or a separate piece of software if I'm ever going to figure out how to do this. It would be nice if Linux devs could come up with a standard so that we could skip this compiling crap and start using the damn software.

[pay]

Have you tried reading the README that comes with the source code?

[Ramses de Norre]

Why a howto? It's as simple as unzip and read the READ_ME and INSTALL files..., all info is in their and if not you should contact the developer.

And a standard is quite impossible because of the big differences between programs, but that's why there are instructions included in every package.

[pay]

The readmes don't have information like where to get the dependencies and they are less specific to Ubuntu. Also, some people look for help here first than elsewhere. And I realise that this is hardly a standard, but I tried to help people that have never compiled anything before to get a general idea of what it is like.

[RedSquirrel]

Howto Compile Source Code on Ubuntu

A few other tools that can come in usefull are automake1.9, libtoolize, subversion, cvs and checkinstall.


I would recommend that you mention the package is named libtool so that people can find it in the repositories. ;)

[Endolith]

2)Browsing the website and extracting it
wget http://downloads.xvid.org/downloads/xvidcore-1.1.2.tar.bz2
tar jxvf xvidcore-1.1.2.tar.bz2(note: for a tar.gz archive use tar zxvf <archive>)

You claim that this is "to help people that have never compiled anything before", but if so, it doesn't seem like you put a lot of thought into what those people are familiar with.

Why do people persist in using the command line for EVERYTHING? This is not helpful at all. A web browser is infinitely more intuitive and familiar than wget. File-roller is much more intuitive than tar, and handles .tar.bz2, .tar.gz, and whatever else, without requiring special command switches for each type.

Ubuntu is supposed to be a user-friendly OS. Please describe user-friendly tools that people are familiar with and do everything "the Ubuntu way" as much as possible, instead of "the old way".

I would recommend that you mention the package is named libtool so that people can find it in the repositories. ;)

Yes. Another example. I couldn't find this in Synaptic. And you should explain what these tools actually do, instead of just saying "tools that can come in usefull". I know checkinstall creates a package in Synaptic, so that it can more easily be upgraded and uninstalled, but why would you mention subversion in a tutorial like this?

[Amazona aestiva]

I just needed this!

Thanks!

[Endolith]

Here are some documents on help.ubuntu.com:

https://help.ubuntu.com/community/CompilingEasyHowTo
https://help.ubuntu.com/community/CompilingSoftware

[netimen]

I have downloaded the newest version of source code and apt-get build-dep says all dependencies are OK (because it checks for the previous version). But ./configure always finds new missing packages and I have to install those packages and then run ./configure from the beginning and wait before it founds a new error. Can I know all missing packages at one time?

[Scimu]

Thanks.. This has gave me a little insight into how you actually do this.

[Blingin2Mingin]

I needed the very latest source code, so I actually found this most helpful,

[picpak]

Alsosudo apt-get –build source will make a generic debian package of the source code.

Can you elaborate more on this? Does it create Debian standard debs? Do you do it to the source package or the source folder?

[the real omni]

Why do people persist in using the command line for EVERYTHING? This is not helpful at all.

On the contrary. I'm generally new to the linux scene, having migrated recently from Vista and having been a long time GUI user.

I personally find how-to's with command line a heck of a lot easier, faster, and more efficient to follow/execute than a GUI-based tutorial as you can accomplish with one copy/paste what takes a series of 10-50 mouse movements and button clicks. Also you don't have to wait for any GUI windows to load before you can click one checkmark and dismiss the window. It's just an extra --OPTION=parameter setting, which is all part of the single copy/paste action.

With a command-line copy/paste it's simply faster and easier to get the job done.

You might not be ingraining the GUI-method into your memory, but every time you read "wget (address-of-remote-file)" you understand more and more what it does and how to use it. (Likewise with any other command-line code) so instead of building your memory based on the slow and inefficient way of doing things, you're building your memory based on the professional, fast, effective way to do things and when you're proficient enough to do it professionally, you're getting 20 minutes work done in 5 by using the command line and thus your time can be worth a lot more money. Even if you're not doing it professionally, it's just good sense to learn the RIGHT way from the start.

Moreover, GUI's change from version to version. Command-line typically stays the same. If tutorials were mainly based on GUI's they'd have to be updated constantly.

I definitely agree that this tutorial is a bit too specific and also a bit too ambiguous in some areas but even as a linux freshman I have to say I prefer command-line-based how-to's nine times out of ten.

One last note: if you actually bite the bullet and make an effort to type out the commands instead of just copy/pasting then you will learn a LOT faster and you'll learn the back-end commands that all the various GUI's use so it won't matter what program/GUI you're trying to work with, you'll know the methodology of getting the job done. As I say I'm new to linux but just by typing out command line instructions for the past couple weeks I've already gotten to the point where I can perform most actions without having to go back and re-consult the walk-through (and in a lot of cases without having to bring up a walk-through at all in the first place).

[Endolith]

You might not be ingraining the GUI-method into your memory, but every time you read "wget (address-of-remote-file)" you understand more and more what it does and how to use it.

A good computer interface wouldn't require you to learn about how the program works in order to use it.

so instead of building your memory based on the slow and inefficient way of doing things, you're building your memory based on the professional, fast, effective way to do things

A good computer interface wouldn't require the memorization of cryptic commands to get things done. The GUI is a better, more efficient interface because it's discoverable. You don't have to read through a manual to figure out how to do something; in a well-written program, it's obvious what you can do from the options presented to you.

Moreover, GUI's change from version to version. Command-line typically stays the same.

Not only do command line tools change from version to version, they change from one program to another. Each has its own idiosyncratic switch syntax that differs from all the rest, requiring you to memorize a separate set of code letters for each program (even for similar options). It is not an intuitive or usable interface, and we should not be recommending it to new users unless no other option exists.

Teaching new users to copy and paste arbitrary commands from the Internet into a terminal without understanding what they do creates a very dangerous mentality that opens them up to exploitation by malicious users. See this notice (http://ubuntuforums.org/announcement.php?f=328) for an example.

[JoshuaRL]

A good computer interface wouldn't require you to learn about how the program works in order to use it.

Well, a good interface might. But a great one will give you a choice as to whether you want to use a GUI or CLI. And it makes all the documentation for either readily available either on the system (man pages or help menus) or online. That way you can choose which you want.

A good computer interface wouldn't require the memorization of cryptic commands to get things done. The GUI is a better, more efficient interface because it's discoverable. You don't have to read through a manual to figure out how to do something; in a well-written program, it's obvious what you can do from the options presented to you.

Well, true. And one thing you have to remember is that you are posting this in a HOWTO for compiling. That is a command line set of instructions. And you really don't need to know how to compile unless you need something really special. For example, if you need a application that is not in the repos, is not available in a convienient DEB, or you need something fully optimized. So, most users don't really need to know this. But if you wanted to make a simple little Python GUI for compiling and keep it up, I'm sure you would have the love of the people.

Not only do command line tools change from version to version, they change from one program to another. Each has its own idiosyncratic switch syntax that differs from all the rest, requiring you to memorize a separate set of code letters for each program (even for similar options). It is not an intuitive or usable interface, and we should not be recommending it to new users unless no other option exists.

Well, not true really for Linux. CLI commands change very little from version to version. And many applications are similar for similar tasks. For instance: APT, Aptitude, and dpkg all have similar CLI phraseology for handling packages. Also, when you do something wrong in CLI it often spits out an error along with help as to how to do it right. I think that qualifies as intuitive.

Teaching new users to copy and paste arbitrary commands from the Internet into a terminal without understanding what they do creates a very dangerous mentality that opens them up to exploitation by malicious users. See this notice (http://ubuntuforums.org/announcement.php?f=328) for an example.

All good points. That's why most of the push is to make HOWTOs GUI unless you need the CLI for some reason. Also, most good HOWTOs explain what the commands mean instead of just "copy this into the terminal."

And I'm sure you'll agree that no amount of security software will stop this kind of "social engineering." The only answer is a slightly questioning mindset and plenty of good instruction. And I believe that Linux, and especially Ubuntu is pretty far along with this. There's so many places to get good information and help from seasoned users.

[LiQuidAiR]

Thank you Pay for taking the time to write this "How To". I did find some of the paragraphs confusing but I found something that compliments your article. Try
http://tuxarena.blogspot.com/2008/09/compiling-cc-code-in-ubuntu-and.html

as it also provides alittle more information to what the first part of the sudo apt-get install build-essential does and how to compile a easy "Hello world!" application.

Regards.

[LiQuidAiR]

I also ran across this:
http://coderstalk.blogspot.com/2008/02/simple-linux-socket-programming-in.html

Here he explains the code from:
http://linuxgazette.net/issue74/tougher.html

The first link listed on this post will direct you on how to start off writing your first socket program. Sockets are used to communicate across a network. This enables more than one computer to talk to each other. I would be more than happy to help anyone with questions. This program was simple enough for me to compile and fix the few bugs I encountered.

I'm very new to this stuff also so please have patience for me as well :)

[BIGtrouble77]

I just had to reply to this howto as some of the comments here are asinine. First off, Pay, thanks for the effort. This is actually pretty useful. I forgot how to create debs from source so it was nice to see a reference to that here.

For those of you who are whining about how hard linux aps are to install realize that Ubuntu has the Add/Remove Software feature specifically for you! You don't even need to fire up Synaptic to install apps. It can't get any easier than that.

Also realize that the ability to compile your software out-of-the-box is an AMAZING feature of gnu linux. It's not straight forward to get a c compiler going in windows, and you are probably going to need to fork over $$ to get one. The gcc compiler in linux is simply an added bonus. You absolutely don't need it to run 99% of the apps you'll use. Most projects have binaries available, and they install just like .exe windows files.

Pay is just trying to help you out if you like running bleeding edge apps or want to install something more obscure that's not in the repos. It's really only going to help you if you have some curiosity to learn a little more about the system you're using. Linux is the ultimate power users/hacker os. The command line stuff should be for fun hacking, use the repositories if you want things to 'just work' quickly.

-bt

edit: lol, I didn't realize this was resurrected from months ago.

[fixerdave]

Just wanted to add my thanks for this quick tutorial - it came up at the top of my Google search.

All I was looking for was a quick example of "what do they mean when they say compile from source?" This tutorial fit the bill just fine. Now, I've got the source for the package I'm interested it, its dependencies, and I'm well on my way to figuring out the rest. Thank you.

Oh, and off-topic but as a professional Windows tech that makes a living installing and supporting software, I firmly believe Ubuntu is way, way, way easier to install software -- just hit the check-box and then OK. It makes the Windows EULA-hell/option-overload OK, OK, OK, OK... look totally stupid. I can get a complete (apps included) install of Ubuntu up and running with less than 5% of the effort involved with Windows, just because I don't have to sit there going OK, OK, OK. Best of all, Ubuntu has an OPTIONAL command-line interface that offers huge amounts of power. And, if I really want to, I can download the source, modify it or some compile options, and then make my own package, which is not off-topic at all :)

David (an Ubuntu convert, can you tell?)

[tyeo098]

Idk why people are nay-saying your tut.
With this tut I installed qemu!

Thanks alot!

[Funnnny]

You should only remember 3 line of code, which are widely using in most of program here:

./configure
make
sudo make install

Most of program will install, if you can get it to work, just read the readme, or Install file, or just ask here.

[brian_hayward]

I realize this post is going to deviate from the subject but does Linux/Ubuntu have a spokesperson? If not, I nominate Funnnny for the job. Pretty sure she would raise a lot of attention for the group.

[hardinej]

I don't know if you'll see this pay or not but I thought it was useful. I needed a new version of something that had to be compiled from source and the sudo apt-get build-dep oldVersion tip was helpful for me. I'm still new and I didn't know that was an option.

[mtinman]

./configure
make
sudo make install

Works fine when you have a configure script in the source package, but what does one do with an older source package that does not contain the configure script? Keep in mind that I do not know yet how to make my own configure script...

[samh785]

I find it interesting that it can only be very insightful or confusing as hell. :P No middle ground?

I did find it fairly easy to understand however, and I applaud you on the effort to make a how-to on the subject.