-------------------------------------------------------------------------------
In general, Unix 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
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.
-------------------------------------------------------------------------------
First, look in the Linux Software Map--it's at sunsite.unc.edu/pub/Linux/docs/linux-software-map, and on the other FTP sites. A search engine is available on the World Wide Web at http://www.boutell.com/lsm/.
Check the FTP sites ``
Where can I get Linux material by FTP?
'' first--search the ls-lR
or INDEX
files
for appropriate strings.
Also look at the Linux Projects Map, ftp.ix.de/pub/ix/Linux/docs/Projects-Map.gz.
There's a search engine for Linux FTP archives at http://lfw.linuxhq.com/
Also check out the Freshmeat Web site http://www.freshmeat.org, which is really cool.
If you don't find anything, you could either download the sources to
the program yourself and compile them. See ``
How do I port XXX to Linux?
'' If it's a large package which may require some
porting, post a message to comp.os.linux.development.apps
.
If you compile a large-ish program, please upload it to one or more of
the FTP sites, and post a message to comp.os.linux.announce
(submit your posting to
linux-announce@news.ornl.gov).
If you're looking for an application program, the chances are that
someone has already written a free verson. The
comp.sources.wanted
FAQ has instructions for finding the
source code.
-------------------------------------------------------------------------------
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 which 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 will use 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 overriden 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 which knows how to do optimisation well for the 586, but it is quite unreliable, especially at high optimisation settings. The Pentium GCC can be found on tsx-11.mit.edu in /pub/linux/ALPHA/pentium-gcc. I'd recommend using the ordinary 486 GCC instead; word has it that using -m386 produces code that's better for the Pentium, 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 currently does the same thing. The Makefiles of newer kernels use -O2, and you should probably do the same.
-------------------------------------------------------------------------------
These are in the directories /usr/include/linux
and
/usr/include/asm
. However, they should be symbolic links to
your kernel sources in /usr/src/linux
, not actual
directories.
If you don't have the kernel sources, download them--see, `` How do I upgrade/recompile my 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-arch directory--if you have a freshly
unpacked kernel source tree you must use 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: unrecognised 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 *.oFor
a.out
, get tools-n.nn.tar.gz from tsx-11.mit.edu, in
/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
sunsite.unc.edu/pub/Linux/docs/HOWTO/
-------------------------------------------------------------------------------
With an ELF compiler (see Q8.2 `What's all this about ELF ?') 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
(see, ``
What's all this about ELF?
'') 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, i.e. one which includes a copy of the C library
instead of using a dynamically linked copy.
Other things worth investigating are -O
and -O2
which enable optimisation (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, most of which are generic packages for any Unix:
-------------------------------------------------------------------------------
Roughly equivalent functionality is built into the GNU C compiler (gcc) which is used by Linux systems. Use the -Wall option to turn on most of the useful extra warnings. Check the GCC manual for more details (type control-h followed by 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 larch.lcs.mit.edu in /pub/Larch/lclint; on the World Wide Web look at http://larch-www.lcs.mit.edu:8001/larch/lclint.html.
-------------------------------------------------------------------------------
Kermit is distributed under a non-GPL copyright that makes its terms of distribution somewhat different. The sources and some binaries are available on kermit.columbia.edu.
The WWW Home Page of the Columbia University Kermit project is http://www.columbia.edu/kermit.
===============================================================================