Originally Posted by Knightron
In addition to this, i'd like to mention source files. If you're using a binary based distro, most of them chop up their packages to reduce the bandwidth needed to install a program. If the package you are compiling has a dependency which is satisfied, but is satisfied via a binary package (installed through the repo); you will likely have to install the dependency's source file too.
When i first tried out compiling, this was my biggest frustration. I had a dependency satisfied, but when i was configuring the source, it was registering that i was missing foo dependency.
A source file is normally named the same name as it's package, with '-devel' or '-source' tagged onto it.
That is more likely to be a library issue not a source issue. the xxx-devel package names are usually libraries - but the libraries are specific to the package, and not to a source application. Applications that are missing system libraries do occur - but that is usually caused by not having (or having partial) configured the system for software development.
Now when using the distributions source package to rebuild a binary package also sometimes have problems - but that is even more directly related to the xxx-devel package.
What I have seen happen is that the source application being built depends on a newer library than what the distribution has provided. This doesn't happen that often, but the older the installation is, the more likely a new application may hit this problem. The only solution then is to get the newer source to the library and build it too. This is what happened to me with Apache - the new Apache depended on a newer OpenSSL library than the one available. So I tended to build both each time, and made sure they were installed in /usr/local well away from where the distribution would put things. I even went so far as to put each application into its own directory in /usr/local. So there would be /usr/local/apache-<version> and /usr/local/OpenSSL-<version>, with a generic link /usr/local/<application> that would point to the current version. Building a new application would always point to the appropriate library, so that once buildt it would always get the corresponding version. If I was using shared libararies, then I could choose to use the symbolic name for the library - and it would then try to use whatever was current.
This allowed me to have multiple versions - an old one, a current one, and a test one... without issues (other than having to specify longer paths to identify which was desired). I could even use /usr/local/bin to contain symbolic links through the /usr/local/<appname> link to get to the utilities. This also made it easy to switch versions for all users. It did mean I occasionally had to clean up broken links though (utility functions that were replaced by new utilities with different names). But nothing all that difficult.
Having all these separated from the system also allowed them to be backed up separately... and even allowed them to be installed (via the backup) on multiple servers.