Printable View
It's not much, and I probably won't use it very often, but I *am* taking a unix certification course (for the knowledge not the actual cert that makes me worth 100K/a), so I needs it.
So I installed Fedora. Don't balk; it installed and that's better than gentoo could have done.
But I've never installed a program on linux before. I *know* it comes in .c files, and I have to compile it. But how do I do this, and how do I run the compiled 'executable'?
;D?
Not necessarily. If you want to compile from source, you're free to, but the more popular route is to use some sort of package management. Fedora/Redhat uses RPMs, which are much easier to install - the drawback being that they won't take care of dependencies for you.
Compiling from source is easy enough in itself, however, dependency and compiler errors become a big problem with it. All you do is change to the install directory, run the config script, the make script, and then the make install script.
cd [directory]
./configure
sudo make
sudo make install
Assuming you have no other problems, that'll do it for you.
If the executable is in the directory you're in: ./executable, other wise, the name is enough (as long as it's in your $path).
The only reason to compile source is if the program doesn't exist in the package format your distro uses or you need an optimized build for your unique system setup. I wouldn't worry too much about being out of date. A lot of the popular distros have backports with the most recent software packages on ftp.
If you really wanna learn *nix, use slackware. I would reccomend it as it is closer to true UNIX than anything else I have encountered. I have honestly never messed with the GUI's, and prefer to run things in console mode.
Slackware is the oldest Linux distribution properly-speaking in existence. Basically Slackware is quite synominous with linux. There is a glorgied quote that gets dropped in the oh so helpful slackware community that goes, "If you learn Red Hat, you learn Red Hat. If you learn SuSE, you learn SuSE. But if you learn Slackware, you learn Linux." It is very true as well.
I think you should really learn how to install by scource, as if you did get in the feild, many business apps, and custom software sets would need to be installed via the scorce. USually there is a great buncha documentation that would come with such software. It is kinda a rule with linux, that you just have to shut up and read the smurfing manual (RTFM) - not to curse, but it is a responce you will get many a time if you post a stupid question that is covered in the manual.
For starters, I would install your distro (SLACKWARE ;) ) with out any software packages then begin the install process, practicing on your way. First, installing Apache, MySQL, and PHP are all fairly easy, and have a ton of documentation online to help you along. Then you have a sweet little webserver for the elle of it.
G'luck - and keep slackin,
Bipper
Yeah, source installation is a great thing to become competent at, since somewhere along the line, you won't be able to RPM or package install something and will need to compile.
Better yet, after compiling a lot of stuff, you'll come to realize that a lot of the package installations really suck and that compiling from source is so much more flexible.
I think to be more accurate, if you know the kernel (GNU/Linux) you know Linux.Quote:
Slackware is the oldest Linux distribution properly-speaking in existence. Basically Slackware is quite synominous with linux. There is a glorgied quote that gets dropped in the oh so helpful slackware community that goes, "If you learn Red Hat, you learn Red Hat. If you learn SuSE, you learn SuSE. But if you learn Slackware, you learn Linux." It is very true as well.
Package management differs according to distro. Package management is one of the few things that separates one distro from another, really. Skip to the bottom paragraph if you want, it's the only important one.
Building software yourself is not simple or easy. Some programs don't use the configure + make toolchain. Some are just a Python or Perl script and don't need to be compiled at all. Some come with a custom script that does some nonstandard crap via Bash. Some use the configure + make toolchain but require additional configuration before it will work, like setting a --prefix or pointing it toward a library it can't find on its own. Some use configure + make but don't have an "install" rule in the Makefile, so you need to skip the "make install" step and copy the files manually to somewhere. Some programs are pre-compiled and the installer script just copies the files to somewhere. There are plenty of other options.
When running configure and make, it's generally
./configure
make
sudo make install
You don't want to run the first "make" as root. All the first make should do is compile the source and leave a binary / binaries ("executable") in the build directories somewhere. All this should presumably be done as a non-root user; there's no need to do it otherwise. You can actually even run the program at that point, directly from the build directories, without actually "installing it". So if a single user needs to install a program but doesn't want everyone else to use it (or doesn't have permissions for everyone else to use it) you're still free to do so.
"make install" moves things around to standard places (generally folders your $PATH, /usr/bin or suchlike) so that you can run the programs more easily and so things are more organized; the only reason it requires root permissions is because you're installing the thing system-wide in system directories. This also allows all users to run the program (generally). But note also that you can configure "make install" to install to ANYWHERE, generally, including somewhere in your home dir, if you feel obliged.
Note also that some distros don't use "sudo", or don't come with a sudo package installed by default. In which case you would "su -" or log in as root in some other way in order to run "make install".
You do have to worry about dependencies; a program that fails the build process will often tell you exactly what it's missing, but won't tell you where to get it or how to build or install it. This is extremely painful, as most programs (especially GUI programs) have many dependencies, which themselves may also have dependencies. Other complications include changes in the compiler itself. If someone writes a program and tests it with GCC 4.0 and it works, but you have GCC 3.4, you may not be able to compile the program merely because it was written for a different compiler version. The same is true if you have the wrong version of certain system libraries. You're then stuck either upgrading your system libraries, or attempting to install multiple versions of system libraries in parallel. (Note, Gentoo handles this quite well. Had to plug Gentoo here at least once, it's the law.)
Of course it is helpful to learn all this, but it's not necessary for someone to know any of this to use Linux, nor should it be, really. There are distros that force you to learn this (Gentoo does) but Gentoo is not for everyone, and other distros are more user-friendly.
The important thing to note here is that building things by hand is not simple. Package managers like RPM installers and Gentoo's Portage and Ubuntu's apt are designed so that some geek sits around and works out all this crap himself, then fixes up in a nice neat package to give you so you can skip the configure/build process as much as possible and just install the thing. In most distros you should never ever see any of this crap, unless you're installing something crazy or non-standard or extremely beta.
Once you realise this, you end up going back to Gentoo :D Maybe you'll have more knowledge about linux by this time so you'd finally be able to install it successfully if you were getting unusual problems before :pQuote:
Better yet, after compiling a lot of stuff, you'll come to realize that a lot of the package installations really suck and that compiling from source is so much more flexible.
Gentoo! ick! wtfzomg. It is all about slackware. Anything else needs to be flushed. plzkthxbai
edit - Slackware's approach to linux is more true to its intent, as to be a UNIX clone. that is what I mean. It is a well known, and reletivly uncontested truth in *nix world ;)