6. Porting, Compiling and Obtaining Programs
6.1. How To Compile Programs.
Most Linux software is written in
C and compiled with the GNU C compiler. GCC
is a part of every Linux distribution. The
latest compiler version, documentation, and
patches are on ftp://ftp.gnu.org/pub/gnu/.
Programs that are written in C++ must be compiled with the GNU G++ compiler,
which is also included in Linux distributions
and available from the same place as GCC.
To build version 2.0.x kernels, you will need GCC version 2.7.2.x, approximately.
Trying to build an early Linux kernel with
a different compiler, like GCC 2.8.x, EGCS,
or PGCC, may cause problems because of GCC
related code dependencies. Kernel versions
2.3 and 2.4 should compile correctly with
more recent compilers.
Information on the EGCS compiler is at http://www.gnu.org/software/gcc/gcc.html.
Note that at this time, the kernel developers are not answering bug requests
for earlier kernels, but instead are concentrating
on developing 2.4.x version kernels and maintaining
2.2.x version kernels.
[J.H.M. Dassen, Axel Boldt]
6.2. How To Install GNU Software.
On a correctly configured system,
installing a GNU software package requires
four steps:
-
With the source.tar.gz archive in the /usr/src/ directory, or wherever you maintain your source files, untar and decompress
the package with the command:
tar zxvf package-name.tar.gz |
Run the ./configure script in the untarred source archive's top-level directory with whatever command
line arguments you need. The options that
configure recognizes are usually contained
in a file called INSTALL or README.
-
Run make. This will build the source code into an executable program (or programs) and
may take a few minutes or a few hours,
depending on the speed of the computer
and the size of the package.
-
Run make install. This will install the compiled binaries, configuration files, and any libraries
in the appropriate directories.
6.4. How To Port XXX to Linux.
In general, *nix programs need very
little porting. Simply follow the installation
instructions. If you don't know—and
don't know how to find out—the answers
to some of the questions asked during the
installation procedure, you can guess, but
this tends to produce buggy programs. In this
case, you're probably better off asking someone
else to do the port. If you have a BSD-ish
program, you should try using -I/usr/include/bsd and -lbsd on the appropriate parts of the compilation lines.
6.5. What Is ld.so and How To Get It?
ld.so is the dynamic library loader. Each binary using shared libraries used to have
about 3K of start-up code to find and load
the shared libraries. Now that code has been
put in a special shared library, /lib/ld.so, where all binaries can look for it, so that it wastes less disk space, and
can be upgraded more easily. ld.so can be obtained from http://tsx-11.mit.edu/pub/linux/packages/GCC/ and mirror sites. The latest version at the time of writing is ld.so.1.9.5.tar.gz. /lib/ld-linux.so.1 is the same thing for ELF ("What's all this about ELF? ") and comes in the same
package as the a.out loader.
6.6. How To Upgrade the Libraries without Trashing the System.
| Warning |
Note: You should always have a rescue disk set ready when you perform this procedure,
in the likely event that something
goes wrong! |
This procedure is especially difficult if you're upgrading very old libraries
like libc4. But you should be able to keep libc4 on the same system with libc5 libraries for the programs that still need them. The same holds true for upgrading
from libc5 to the newer-yet glibc2 libraries.
The problem with upgrading dynamic libraries is that, the moment you remove the
old libraries, the utilities that you need
to upgrade to the new version of the libraries
don't work. There are ways around around this.
One is to temporarily place a spare copy of
the run time libraries, which are in /lib/, in /usr/lib/, or /usr/local/lib/, or another directory that is listed in the /etc/ld.so.conf file.
For example, when upgrading libc5 libraries, the files in /lib/ might look something like:
libc.so.5
libc.so.5.4.33
libm.so.5
libm.so.5.0.9 |
These are the C libraries and the math libraries. Copy them to another directory
that is listed in /etc/ld.so.conf, like /usr/lib/:
$ cp -df /lib/libc.so.5* /usr/lib/
$ cp -df /lib/libm.so.5* /usr/lib/
$ ldconfig |
Be sure to run ldconfig to upgrade the library configuration.
The files libc.so.5 and libm.so.5 are symbolic links to the actual library files. When you upgrade, the new links
will not be created if the old links are still
there, unless you use the -f flag with cp. The -d flag to cp will copy the symbolic link itself, and not the file it points to.
If you need to overwrite the link to the library directly, use the -f flag with ln.
For example, to copy new libraries over the old ones, try this. Make a symbolic
link to the new libraries first, then copy
both the libraries and the links to /lib/, with the following commands.
$ ln -sf ./libm.so.5.0.48 libm.so.5
$ ln -sf ./libc.so.5.0.48 libc.so.5
$ cp -df libm.so.5* /lib
$ cp -df libc.so.5* /lib |
Again, remember to run ldconfig after you copy the libraries.
If you are satisfied that everything is working correctly, you can remove the
temporary copies of the old libraries from
/usr/lib/ or wherever you copied them.
6.7. How To Use Code or a Compiler Compiled for a 486 on a 386.
Yes, unless it's the kernel.
The -m486 option to GCC, which is used to compile binaries for x486 machines, merely changes certain
optimizations. This makes for slightly larger
binaries that run somewhat faster on a 486.
They still work fine on a 386, though, with
a small performance hit.
However, from version 1.3.35 the kernel uses 486 or Pentium-specific instructions
if configured for a 486 or Pentium, thus making
it unusable on a 386.
GCC can be configured for a 386 or 486; the only difference is that configuring
it for a 386 makes -m386 the default and configuring for a 486 makes -m486 the default. In either case, these can be overridden on a per-compilation basis
or by editing /usr/lib/gcc-lib/i*-linux/ n.n.n/specs.
There is an alpha version of GCC that knows how to do optimization well for the 586, but it is quite unreliable,
especially at high optimization settings.
The Pentium GCC can be found on ftp://tsx-11.mit.edu/pub/linux/ALPHA/pentium-gcc/. The ordinary 486 GCC supposedly produces better code for the Pentium using
the -m386, or at least slightly smaller.
6.8. What Does ``gcc -O6'' Do?
Currently, the same as -O2 (GCC 2.5) or -O3 (GCC 2.6, 2.7). Any number greater than that does the same thing. The Makefiles of newer kernels use -O2, and you should probably do the same.
6.9. Where Are linux/*.h and asm/*.h?
The files /usr/include/linux/ and /usr/include/asm/ are often soft links to the directories where the kernel headers are. They are
usually under /usr/src/kernel*/.
If you don't have the kernel sources, download them. Refer to the answer: (``How To Upgrade/Recompile a Kernel.'')
Then, use rm to remove any garbage, and ln to create the links:
$ rm -rf /usr/include/linux /usr/include/asm
$ ln -sf /usr/src/linux/include/linux /usr/include/linux
$ ln -sf /usr/src/linux/include/asm /usr/include/asm |
/usr/src/linux/include/asm/ is a symbolic link to an architecture-specific asm directory. If you have a freshly unpacked kernel source tree, you must make
symlinks. You'll also find that you may need
to do `make config' in a newly-unpacked kernel
source tree, to create linux/autoconf.h.
6.12. Programs Are Very Large.
With an ELF compiler (``What's All This about ELF? glibc?''), the most common cause of large executables is the lack of an appropriate
.so library link for one of the libraries
you're using. There should be a link like
libc.so for every library like libc.so.5.2.18.
With an a.out compiler the most common cause of large executables is the -g linker (compiler) flag. This produces (as well as debugging information in the
output file) a program which is statically
linked—one which includes a copy of
the C library instead of a dynamically linked
copy.
Other things worth investigating are -O and -O2, which enable optimization (check the GCC documentation), and -s (or the strip
command) which strip the symbol information
from the resulting binary (making debugging
totally impossible).
You may wish to use -N on very small executables (less than 8K with the -N),
but you shouldn't do this unless you understand
its performance implications, and definitely
never with daemons.
6.13. Does Linux Support Threads or Lightweight Processes?
As well as the Unix multiprocessing
model involving heavyweight processes, which
is of course part of the standard Linux kernel,
there are several implementations of lightweight
processes or threads. Recent kernels implement
a thread model, kthreads. In addition, there
are the following packages available for Linux.
Please contact the authors of the packages in question for details.
