Despite being answered a kajillion times before, this question warrants a response.

Compiling from the source has the following advantages:

1) Assuming the source package uses a build system like GNU autoconf/automake or BSD/Plan9 mk, customising programs to your needs and to your OS's environment is very streamlined.

2) Compiling allows you to optimise the binaries for your specific CPU; or, if you feel like cross-compiling to any CPU architecture and features you could imagine. The CFLAGS and CXXFLAGS environment variables are very useful for setting optimisation flags for ./configure scripts.
See: http://en.gentoo-wiki.com/wiki/Safe_Cflags and the man page for gcc.

3) Allows you to very specifically install packages to wherever you wish. I tend to keep compiled packages in /usr/local/packagename/packageversion, and have yet to find a package manager that will do the same for me.

For instance, Arch's default i686 setup comes with a kernel and packages compiled to run on any and every i686 CPU. This means everything from the Pentium II on up. If you have a Pentium 4, you should know that your CPU has quite a few more features than the Pentium II, and you want your programs to use any or all of the available extra features so that it can run faster and more efficiently.
Recompiling the packages from the source code with the appropriate optimisation flags (See $CFLAGS and $CXXFLAGS for ./configure scripts) will allow you to build highly optimised binaries for *your* CPU.

It's worth noting that Gentoo's portage, Net/OpenBSD's pkgsrc, and the FreeBSD ports tree all compile their packages from source code that has been patched to fit the respective systems and environments, and all three have conventions for specifying default optimisation flags to pass to gcc.

>>255
And you can screw around with it before you compile it.

>>256
Yeah, I knew I forgot something when I hit Submit.

Compiling from source allows you to modify the source if you care to. If you're good enough with code, you may even spot potential security risks or incompatiblities especially for your particular system.

I've to compile ices0 (the icecast client) from source, and they haven't updated the code since before FLAC changed their API. As such, I had to patch the source files that dealt with decoding FLAC to comply with the new API, and it works wonderfully after that.

*Most of the time*, you won't have to dick around with the source unless you really want to. It's just something to keep in mind.

>>254
thanks for the detailed response. i appreciate it. i will be installing arch, currently running ubuntu, should i compile the arch kernel from source so that it runs best on my cpu? or will i notice a difference by just installing the arch default setup?

also when you mention optimizing the binaries for your specific cpu, is this done during the compiling process? or is it something that must be done before hand?

>>258
Typically you install Arch first, then you compile a custom kernel if you'd like. Depending on how much newer your system is than the reference for the architecture you pick (Pentium II for i686, Athlon 64 for x86_64), you might notice a valuable difference compiling a customised kernel. Besides, when you configure your own kernel, you can strip out the stuff you don't really need, and smaller binaries can mean faster response.
There are instructions at http://wiki.archlinux.org/index.php/Kernel_Compilation_From_Source , and you can typically copy /proc/config.gz so you don't have to configure the entire kernel from scratch. If you're going the optimisation route, you should look under "Processor type and features" in the menuconfig to select your specific processor brand.

Optimising happens during the compilation process. Arguments known as Cflags and Cxxflags (for C and C++, respectively) are generally exported to your environment as $CFLAGS and $CXXFLAGS, and are used by ./configure scripts and various other build systems to know what to pass to the compiler to optimise the code.

For instance:
$ echo $CFLAGS
-march=k8 -O3 -pipe -fomit-frame-pointer -s

When a ./configure script is run, it will (usually, but unfortunately not always) generate Makefiles containing these arguments to pass to gcc when you run make(1). You can read the man page for gcc(1) to figure out what those arguments do.

If you on an Ubuntu or Debian system you can also use checkinstall to wrap the executables into a package and install them. The package can later be removed easily with apt.

God, this thread reminds me of the Gentoo ricers.

>>311
And why is that? Because you're too lazy to learn to optimize your code, or too ignorant to see the differences that optimization can and often do provide?

>>349

You mean the very marginal performance benefit? You gain far more measurable gains by switching to ICC than by aggressively optimizing your CFLAGS.

>>429
That, sir, would still be optimizing, just for a specific platform.

>>431

Indeed, and in fact, it still isn't beneficial enough to warrant the time invested either way.

lol, "aggressively optimizing"
lol, "time invested"

CFLAGS='-march=native -O3 -pipe -s'

There, copy and paste that. And stop using shitty computers that take hours to compile.

>>446

Just remember- that's O3 the letter, not 03 the number.

6. Installing packages from source

* A lot of programs and libraries for Linux are written in C or C++. Initially the program consists of text files which can be read and edited with a text editor. In a second step these files can be compiled with a compiler. On linux this will probably be the GNU C compiler (gcc or g++). The compiler will transform the text files into binary code, which can be executed on your system (You could say that the human language is converted into computer language). When everything is compiled and ready, the different pieces of the program or library can be installed on your system.
* Source packages are often distributed in the form of a tar archive. A tar archive is actually a collection of files that are stored as one file with the .tar extension. The archive can be created or extracted with the tar utility. The name "tar" is derived from "tape archive" as tar was historically used to make backups to tape drives. A tar archive does not use file compression techniques to make the file smaller. That's why tar archives are usually compressed with the standard linux compression tools: gzip (extension .gz) and bzip2 (extension .bz2). As a result, source packages often have two extensions (e.g. archive.tar.gz), and they are often called tarballs. Modern versions of tar will uncompress the tarball automatically for you. The typical command to uncompress and extract a tarball is: 'tar -xvf archive.tar.gz' . The "-x" option tells tar to extract, "-v" tells tar to be verbose (show the files that are extracted), "-f" tells tar that it has to extract from a file.
* When you have extracted the tarball, a new directory will be made, with the contents of the archive. Now we can start building the program. First we 'cd' into the directory, and read the README and INSTALL files. These files often contain information about the dependencies of the program, instructions to build or install the program, etc. We can install the needed dependencies with Synaptic. But we have to make sure that for every dependency, we have the corresponding development package installed as well. These packages have the same name as the original package, but with the "-dev" postfix. They are only necessary when you want to compile programs from source. The first command we have to give is ./configure. This script is provided by the source package, and it checks what building tools we use on our system, if the necessary dependencies are installed, and a lot more. It is very likely that it will return an error because something is missing on your system. Just have a look at the error, and install the necessary package. You have to repeat this process until the './configure' command succeeds [10]. Now we can type make in the terminal. The 'make' command will build everything needed for the package. This might take a while, depending on how large the program is. Now we are ready to install the necessary components on our system. Source packages should install their files in the '/usr/local/' hierarchy by default. You will need root privileges to do the installation. To install, we type sudo make install in the terminal. The executables will now be installed in the '/usr/local/bin' directory, and you can now use them as any other command.
* One of the difficulties with installed source packages, is that it is not so easy to uninstall them. Sometimes you will be able to issue sudo make uninstall from within the source package directory. But this will not always be the case. And once the files are installed in the '/usr/local' hierarchy, it is very hard to know which files belongs to which package. That is why I would like to introduce you to the 'Stow' system. The idea is that we install every package we build from source into it's own subdirectory in the '/usr/local/stow' directory. When this is done, we can use the stow command to make links in the '/usr/local' hierarchy for every file in that subdirectory. Now our system will recognize the programs and libraries we installed. When we want to delete a package, we can use 'stow' again to delete all the links for that package in the '/usr/local' hierarchy. And we can start from a clean slate again. Stow makes it also very easy to have multiple versions of a package installed. You can install them next to each other in the '/usr/local/stow' directory. The system won't know about them until you make the necessary links with stow. To use a newer version of a program, you delete the links to the older version, and make new ones to the new version. Completely deleting a package from your system is very simple as well. Just delete the links with the 'stow' command, and remove the directory of that program.
* I will now give you an example of installing a source package with the help of stow (You have to install the stow package with synaptic first). Lets say that we want to install a package named package-1.2 .We compile the package first with the ./configure and make commands (it doesn't matter from where). Then we install the package in its own directory in the stow directory with: sudo make install prefix=/usr/local/stow/package-1.2. Now we have to cd into the stow directory (/usr/local/stow), and let stow create the necessary links with this command: stow package-1.2. To delete the links to your package again type stow -D package-1.2 from the '/usr/local/stow' directory.

Thank you Google.

Because sometimes people update the source before they update the one that is already built. The source is like a BETA for what is to come.

Well, if there is a package available for your distribution there really is no advantage for compiling out of source.

The package manager makes it easier to remove it later and also the package manager has a list of installed items, so you can know exactly what you have in your OS.

I mean, compiling something could give you the option to optimize it for your CPU and such, but, most likely, it will not give you any kind of noticeable performance boost.

>>607
>but, most likely, it will not give you any kind of noticeable performance boost.
Tell that to anyone who's ever built their whole operating system from source rather than using precompiled binaries.

As for the problems uninstalling it or whatever later a good OS will have tools to make that easier, debian based distros have apt-build, I don't know about red-hat based. I recommend using gentoo if you plan on compiling things though, so much easier to use than debian if you plan to do lots of compiling.

>>621
> Tell that to anyone who's ever built their whole operating system from source rather than using precompiled binaries.

I did that once. Didn't notice a difference. Maybe because I didn't spend weeks trying to see what parameters give me those performance boosts.

It is a time-consuming endeavour and the only satisfaction you get from it is that you can say "Oh, yeah. I compile packages!"

Desktop users, such as myself, need stuff that works and need it quickly. I don't have time to hunt for dependencies (one of the reasons I switched from using Slackware all the time). I want to do aptitude/yum/pacman/yast2 install package1 package2 ... and start using it right away.

I don't want to spend hours compiling it and the required dependencies only to find out it is two in the morning and too late to do anything productive...

>>625
Actually, I've noticed most enterprise users tend to need precompiled binaries to get things up and running. Desktop users have more time on their hands, and therefore compile more often.

>>254
'Cause, PowerPC5 and PowerPC6 has completely different architecture. A bin compiled for PPC5 will be extremely slow on PPC6. Like all even vs odd series, one series is optimized for cascade floating-point operations the other series is optimized for vector operations. This difference in architecture lets the compiler rearrange its arithmetics and unfold its for-loop differently in optimization. One wants to keep the results from its last operation in the accumulator and avoid busing data around as much as possible and use that as an operand in the next operation. The other wants to do two separate operation at the same time and don't want to avoid busing around the four operands of the input and two operands of the output if it means it can do more operations are the same time.

All this becomes even more crazy in the PS3 Cell architecture. If you ever tried to compile Linux application on a PS3 you would soon realize that it has a 64-bit core optimized for doing cascade floating-point operations while seven 32-bit core with 128-bit register optimized for doing 4 separate 32-bit operations. There is a 300x performance difference if you don't know what you are doing.

>>661
This brings up an excellent observation.

I've going to guess that most of the people complaining about how marginal the performance boost is are only using x86 or x86_64 procs, the former of which has been mostly the same since the 80386, with rather specialised extensions such as MMX, 3DNow!, and the SSEs; specialised meaning for the types of programs that have been built for Windows since 95. I think it's safe to assume that until sometime after the turn of the millenium, neither Intel nor AMD were really worrying about what was being written for *nix.
With these architectures, the difference is probably marginal with respect to most POSIX and Linux programs that don't fully utilise the extensions to the architecture, the bigger address space of 64 bit processing, or the extra cores provided by an SMP-capable system.

I don't claim to know many of the technical details of the POWER arch, but it seems the above poster has gotten the less subtle differences of the different versions of PowerPC, as well as the wonderful Cell/B.E. down.

>>574
RAGE

>>574

A TROLL

>>574
Winfag, check out the Linux Unified Kernel.
https://secure.wikimedia.org/wikipedia/en/wiki/Linux_Unified_Kernel
It's a Linux kernel that can run NT binary. It's the bastard child of Winfags and Nixfags. Some started to call it, WinNix, as a parody of Lindows. You can compile WINE lib and GNU lib on it. Or, don't compile anything if you trust the binary blob you downloaded.

>>820
I hope this works. Getting Fedora for this tonight.

Does the Linux Unified Kernel suffer from the Exploit Wednesday?

>>429
how would switching to icc not require recompilation to begin with?

to be honest, i think the most interesting idea would be a distro that distributes packages as llvm bytecode. that would cut compile time by, theoretically, a factor of ten, while retaining any important cpu-specific optimizations.

distributing GIMPLE (the gcc intermediate representation) could theoretically work just as well, though i'm not sure how well gcc would like that.

>>820
>Or, don't compile anything if you trust the binary blob you downloaded.

From a reputable source, I trust a binary just as much as I trust over 9000 text files.

hell yeah. why leave the repositories anyways?

>>1478
I'm going to hope you're trollin'.

I like having a already compiled make source on my computer so if I see the tiniest thing I don't like I can change it within a few minutes.

Increases power over the machines.

>>429

I mean, most things just run fast enough in the first place to not need to worry about *any* speed increases, because if something's more or less instantaneous, then so what if it could be faster?

Time should be spent recompiling things that you'd actually care to see speed up. How many of those things are there that let you manually compile in the first place? Not that many.

Compiling from source is mostly a bad idea. It's a waste of time and can easily make your system unstable if you just throw some random cool-sounding flags to gcc. Even if it works, it probably won't be any faster.

Compiling some critical apps like video encoders with flags that have been proven by testing to produce faster code is OK.

>>2031
I've never had any problem with it. Using Slackware it's pretty much required for a lot of programs. Gentoo too; which I used for a few years.

why is this still stickied?

>>2138
Because there's probably no mod here. Either that or he posted something in the thread he's particularly proud of and wants everyone to see it.

>>2138
Because its a good thread, it answers a question lots of people have about linux. Personally, I'm not unstickying it because I know this question is going to come up several hundred more times.