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]
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.
The Sun Microsystems Java Developer's Kit (JDK) Version 1.2, is at http://java.sun.com/products/jdk/1.2/download-linux.html.
You can also get the source code, which is licensed by Sun Microsystems.
Kaffee, an Open-Source version of Java, is at http://www.transvirtual.com/products/.
The home page of IBM's Jikes Java compiler is http://www10.software.ibm.com/developerworks/opensource/jikes.
There is a version of Sun's HotJava browser for Linux at http://www.java.sun.com/products/hotjava/.
Netscape Communicator comes with its own version of the Java Runtime Environment, so if you need Java only to view Web graphics, you may already have the runtime version of the Java Virtual Machine and libraries that you need installed on your system. You can download Communicator from http://www.netscape.com/.
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.
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.
| 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.
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.
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.
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.
See the previous question regarding the header files.
Remember that when you apply a patch to the kernel, you must use the ``-p0'' or ``-p1'' option: otherwise, the patch may be misapplied. See the patch manual page for details.
``ld: unrecognized option `-qmagic''' means that you should get a newer linker, from ftp://tsx-11.mit.edu/pub/linux/packages/GCC/, in the file binutils-2.8.1.0.1.bin.tar.gz.
For ELF,
$ gcc -fPIC -c *.c $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o |
For a.out, get tools-n.nn.tar.gz from tsx-11.mit.edu/pub/linux/packages/GCC/src/. It comes with documentation that will tell you what to do. Note that a.out shared libraries are a very tricky business. Consider upgrading your libraries to ELF shared libraries. See the ELF HOWTO, at ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/
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.
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.
GNU glibc2 for Linux has optional support for threads. The archive is available from the same place as glibc2, ftp://ftp.gnu.org/pub/gnu/
In sipb.mit.edu:/pub/pthread/ or ftp.ibp.fr:/pub/unix/threads/pthreads. Documentation isn't in the package, but is available on the World Wide Web at http://www.mit.edu:8001/people/proven/home_page.html. Newer Linux libc's contain the pthreads source. The GNU Ada compiler on ftp://metalab.unc.edu/pub/Linux/devel/lang/ada/gnat-3.01-linux+elf.tar.gz contains binaries made from that source code.
In ftp://ftp.cs.washington.edu:/pub/qt-001.tar.Z is QuickThreads. More information can be found in the technical report, available on the same site is /tr/1993/05/UW-CSE-93-05-06.PS.Z.
In gummo.doc.ic.ac.uk/rex/ is lwp, a very minimal implementation.
In ftp://ftp.cs.fsu.edu:/pub/PART/, an Ada implementation. This is useful mainly because it has a lot of Postscript papers that you'll find useful in learning more about threads. This is not directly usable under Linux.
Please contact the authors of the packages in question for details.
Roughly equivalent functionality is built into GCC. Use the -Wall option to turn on most of the useful extra warnings. See the GCC manual for more details (type F1-i in Emacs and select the entry for GCC).
There is a freely available program called lclint that does much the same thing as traditional lint. The announcement and source code are available at on ftp://larch.lcs.mit.edu/pub/Larch/lclint/; on the World Wide Web, look at http://lclint.cs.virginia.edu/.
Kermit is distributed under a non-GPL copyright that makes its terms of distribution somewhat different. The sources and some binaries are available on ftp://kermit.columbia.edu.
The WWW Home Page of the Columbia University Kermit project is http://www.columbia.edu/kermit/.
The www.CablemodemInfo.com and xDSL Web page at http://www.cablemodeminfo.com/ has a section devoted to Linux.
Several ICQ clients are available on metalab.unc.edu. (Refer to: ``Where Are the Linux FTP Archives?'') ICQ itself does not have a Linux client, but there is a Java client at http://www.mirabilis.com/download/.