Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Compiling from source is a good way to do things. There are plenty of tutorials on the web and here within linuxquestions, as it is a common problem.

You seem to already have the basic jist of things, and that is to do ./configure, make, and make install. The extra info that may be passed to configure can make or break the whole deal. Here is what I usually do when compiling something new.

I start with ./configure --help. That will usually give you a list of all the options that configure will take. 9 times out of 10 you don't need to do anything besides ./configure. As you watch the output of configure, if there are problems it will tell you, say for example it can't find a certain library file. At that point you may need to pass info into configure, like the location of the library it couldn't locate on its own. You'll also hit errors if it is looking for something you don't have, in which case you need to install it yourself.

Once configure gets done successfully, make follows. Usually if configure is cool, make is cool, and then make install as root does the rest. I usually use /usr/local ans the location to unzip the gzip or bz2 file. To do that you usually need to be root as well, so the entire ./configure make make install all gets done as root. Other folks prefer to do all their source installations in their home directory, that way they don't need to be root except for the make install step.

For the most part, the more you do the source compilations, the better you get at it, and the better you are at getting around the problems that come up.

The main downside to doing source compilations is it isn't nearly as easy as installing from the .deb or .rpm, or using aptitude, yum, emerge, or whatever. Once it is more comfortable, you have the issue that you don't get software updated automatically when a new version comes out. If your package manager installs firefox 1.5.0.3, and 1.5.1.0 comes out, your manager will update you. If you are running firefox 1.5.0.3 that you compiled yourself, you will never be upgraded automatically, it will take you downloading the source for the update, and again going through the compilation and installing. Not a huge problem, it just isn't as easy. The nice thing is once you get some version of a program installed, you probably have all the requirements, so upgrading will be just a configure, make, make install.

The makefile is included in the package or generated in the the configure step. It will appear most often in the directory where the tar.gz or tar.bz2 file was unzipped. At that point you could just edit the Makefile and include the line you read about.

The origin of Makefiles has already been explained. As for netcat, all you have to do is put something like

Code:

DFLAGS = -DGAPING_SECURITY_HOLE

in the beginning part of the Makefile. Netcat was written before `autoconf' and friends became popular (autoconf is what uses configure scripts to make sure the code compiles well on different setups).

In case you are a little curious about how such an expression magically causes the program to include the -e option, it is quite simple. In general, a Makefile provides

Instructions to the computer on how to compile the code.

A way to see what internal dependencies are (i.e., what files have to be recompiled when a simple change is made to one of the source files).

The -D option (to the c compiler) defines whatever comes after it when compiling code. The netcat.c has a check that happens at the preprocessor level to know what code to leave out.

If you just want the necessary mod's made to the Makefile, just post the first 25 or so lines of it here. Someone can add the extra line, and you can copy it back into your version. If you want a full description of how make works, that might be a little beyond the scope of this forum.