home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit v2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Unix / HOWTOs / GCC-HOWT < prev    next >
Text File  |  1999-11-04  |  62KB  |  1,915 lines
  1.   The Linux GCC HOWTO
  2.   Daniel Barlow <dan@detached.demon.co.uk>
  3.   v1.17, 28 February 1996
  4.  
  5.   This document covers how to set up the GNU C compiler and development
  6.   libraries under Linux, and gives an overview of compiling, linking,
  7.   running and debugging programs under it.  Most of the material in it
  8.   has been taken from Mitch D'Souza's GCC-FAQ, which it replaces, or the
  9.   ELF-HOWTO, which it will eventually largely replace.  This is the
  10.   first publically released version (despite the version number; that's
  11.   an artifact of RCS).  Feedback is welcomed.
  12.  
  13.   1.  Preliminaries
  14.  
  15.   1.1.
  16.  
  17.   ELF vs. a.out
  18.  
  19.   Linux development is in a state of flux right now.  Briefly, there are
  20.   two formats for the binaries that Linux knows how to execute, and
  21.   depending on how your system is put together, you may have either.
  22.   When reading this HOWTO, it helps to know which.
  23.  
  24.  
  25.  
  26.   How to tell?  Use the `file' utility (eg file /bin/bash).  For an ELF
  27.   program it will say something with ELF in, for an a.out program it
  28.   will say something involving Linux/i386.
  29.  
  30.   The differences between ELF and a.out are covered (extensively) later
  31.   in this document.  ELF is the newer format, and generally accepted as
  32.   better.
  33.  
  34.  
  35.   1.2.  Administrata
  36.  
  37.   The copyright information and like legalese can be found at the end of
  38.   this document, together with the statutory warnings about asking dumb
  39.   questions on Usenet, revealing your ignorance of the C language by
  40.   reporting bugs which aren't, and picking your nose while chewing gum.
  41.  
  42.  
  43.   1.3.  Typography
  44.  
  45.   If you're reading this in Postscipt, dvi, or html format, you get to
  46.   see a little more font variation than people with the plain text
  47.   version.  In particular, filenames, commands, command output and
  48.   source code excerpts are set in some form of typewriter font, whereas
  49.   `variables' and random things that need emphasizing are empasized.
  50.  
  51.   You also get a usable index.  In dvi or postscript, the numbers in the
  52.   index are section numbers.  In HTML they're just sequentially assigned
  53.   numbers that you can click on.  In the plain text version, they really
  54.   are just numbers.  Get an upgrade!
  55.  
  56.   The Bourne (rather than C) shell syntax is used in examples.  C shell
  57.   users will want to use
  58.  
  59.  
  60.        % setenv FOO bar
  61.  
  62.  
  63.  
  64.  
  65.   where I have written
  66.  
  67.   $ FOO=bar; export FOO
  68.  
  69.  
  70.  
  71.  
  72.   If the prompt shown is # rather than $, the command shown will
  73.   probably only work as root.  Of course, I accept no responsibility for
  74.   anything that happens to your system as a result of trying these
  75.   examples.  Have a nice day :-)
  76.  
  77.  
  78.  
  79.   2.  Where to get things
  80.  
  81.   2.1.  This document
  82.  
  83.   This document is one of the Linux HOWTO series, so is available from
  84.   all Linux HOWTO repositories, such as
  85.   <http://sunsite.unc.edu/pub/linux/docs/HOWTO/>.  The HTML version can
  86.   also be found (possibly in a slightly newer version) from
  87.   <http://ftp.linux.org.uk/~barlow/howto/gcc-howto.html>.
  88.  
  89.  
  90.   2.2.  Other documentation
  91.  
  92.   The official documentation for gcc is in the source distribution (see
  93.   below) as texinfo files, and as .info files.  If you have a fast
  94.   network connection, a cdrom, or a reasonable amount of patience, you
  95.   can just untar it and copy the relevant bits into /usr/info.  If not,
  96.   you may find them at tsx-11
  97.   <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/>, but not necessarily
  98.   always the latest version.
  99.  
  100.  
  101.  
  102.  
  103.   There are two source of documentation for libc.  GNU libc comes with
  104.   info files which describe Linux libc fairly accurately except for
  105.   stdio.  Also, the manpages <ftp://sunsite.unc.edu/pub/Linux/docs/>
  106.   archive are written for Linux and describe a lot of system calls
  107.   (section 2) and libc functions (section 3).
  108.  
  109.  
  110.   2.3.  GCC
  111.  
  112.   There are two answers.
  113.  
  114.   (a) The official Linux GCC distribution can always be found in binary
  115.   (ready-compiled) form at
  116.   <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/>.  At the time of
  117.   writing, 2.7.2 (gcc-2.7.2.bin.tar.gz) is the latest version.
  118.  
  119.   (b) The latest source distribution of GCC from the Free Software
  120.   Foundation can be had from GNU archives
  121.   <ftp://prep.ai.mit.edu/pub/gnu/>.  This is not necessarily always the
  122.   same version as above, though it is just now.  The Linux GCC
  123.   maintainer(s) have made it easy for you to compile the latest version
  124.   available yourself --- the configure script should set it all up for
  125.   you.  Check tsx-11 <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/> as
  126.   well, for patches which you may want to apply.
  127.  
  128.   To compile anything non-trivial (and quite a few trivial things also)
  129.   you will also need the
  130.  
  131.  
  132.  
  133.   2.4.  C library and header files
  134.  
  135.   What you want here depends on (i) whether your system is ELF or a.out,
  136.   and (ii) which you want it to be.  If you're upgrading from libc 4 to
  137.   libc 5, you are recommended to look at the ELF-HOWTO from
  138.   approximately the same place as you found this document.
  139.  
  140.   These are available from tsx-11
  141.   <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/> as above:
  142.  
  143.  
  144.  
  145.      libc-5.2.18.bin.tar.gz
  146.         --- ELF shared library images, static libraries and include
  147.         files for the C and maths libraries.
  148.  
  149.  
  150.      libc-5.2.18.tar.gz
  151.         --- Source for the above.  You will also need the .bin. package
  152.         for the header files.  If you are deliberating whether to
  153.         compile the C library yourself or use the binaries, the right
  154.         answer in nearly all cases is to use the binaries.  You will
  155.         however need to roll your own if you want NYS or shadow password
  156.         support.
  157.  
  158.  
  159.      libc-4.7.5.bin.tar.gz
  160.         --- a.out shared library images and static libraries for version
  161.         4.7.5 of the C library and friends.  This is designed to coexist
  162.         with the libc 5 package above, but is only really necessary if
  163.         you wish to keep using/developing a.out format programs.
  164.  
  165.  
  166.   2.5.
  167.  
  168.  
  169.  
  170.   Associated tools (as, ld, ar, strings etc)
  171.  
  172.   From tsx-11 <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/>, just like
  173.   everything else so far.  The current version is
  174.   binutils-2.6.0.2.bin.tar.gz.
  175.  
  176.  
  177.   Note that the binutils are only available in ELF, the current libc
  178.   version is in ELF and the a.out libc is happiest when used in
  179.   conjunction with an ELF libc.  C library development is moving
  180.   emphatically ELFwards, and unless you have really good reasons for
  181.   needing a.out things you're encouraged to follow suit.
  182.  
  183.  
  184.  
  185.  
  186.   3.  GCC installation and setup
  187.  
  188.   3.1.
  189.  
  190.  
  191.   GCC versions
  192.  
  193.   You can find out what GCC version you're running by typing gcc -v at
  194.   the shell prompt.  This is also a fairly reliable way to find out
  195.   whether you are set up for ELF or a.out.  On my system it does
  196.  
  197.  
  198.  
  199.   $ gcc -v
  200.   Reading specs from /usr/lib/gcc-lib/i486-box-linux/2.7.2/specs
  201.   gcc version 2.7.2
  202.  
  203.  
  204.  
  205.  
  206.  
  207.   The key things to note here are
  208.  
  209.   o  i486.  This indicates that the gcc you are using was built for a
  210.      486 processor --- you might have 386 or 586 instead.  All of these
  211.      chips can run code compiled for each of the others; the difference
  212.      is that the 486 code has added padding in some places so runs
  213.      faster on a 486.  This has no detrimental performance effect on a
  214.      386, but does make the binaries slightly larger.
  215.  
  216.   o  box.  This is not at all important, and may say something else
  217.      (such as slackware or debian) or nothing at all (so that the
  218.      complete directory name is i486-linux).  If you build your own gcc,
  219.      you can set this at build time for cosmetic effect.  Just like I
  220.      did :-)
  221.  
  222.   o  linux.  This may instead say linuxelf or linuxaout, and,
  223.      confusingly, the meaning of each varies according to the version
  224.      that you are using.
  225.  
  226.  
  227.   o  linux means ELF if the version is 2.7.0 or newer, a.out otherwise.
  228.  
  229.   o  linuxaout means a.out.  It was introduced as a target when the
  230.      definition of linux was changed from a.out to ELF, so you won't see
  231.      any linuxaout gcc older than 2.7.0.
  232.  
  233.  
  234.  
  235.   o  linuxelf is obsolete.  It is generally a version of gcc 2.6.3 set
  236.      to produce ELF executables.  Note that gcc 2.6.3 has known bugs
  237.      when producing code for ELF --- an upgrade is advisable.
  238.  
  239.   o  2.7.2 is the version number.
  240.  
  241.   So, in summary, I have gcc 2.7.2 producing ELF code.  Quelle surprise.
  242.  
  243.  
  244.   3.2.  Where did it go?
  245.  
  246.   If you installed gcc without watching, or if you got it as part of a
  247.   distribution, you may like to find out where it lives in the
  248.   filesystem.  The key bits are
  249.  
  250.  
  251.   o  /usr/lib/gcc-lib/target/version/ (and subdirectories) is where most
  252.      of the compiler lives.  This includes the executable programs that
  253.      do actual compiling, and some version-specific libraries and
  254.      include files.
  255.  
  256.   o  /usr/bin/gcc is the compiler driver --- the bit that you can
  257.      actually run from the command line.  This can be used with multiple
  258.      versions of gcc provided that you have multiple compiler
  259.      directories (as above) installed.  To find out the default version
  260.      it will use, type gcc -v.  To force it to another version, type gcc
  261.      -V version.  For example
  262.  
  263.  
  264.  
  265.   # gcc -v
  266.   Reading specs from /usr/lib/gcc-lib/i486-box-linux/2.7.2/specs
  267.   gcc version 2.7.2
  268.   # gcc -V 2.6.3 -v
  269.   Reading specs from /usr/lib/gcc-lib/i486-box-linux/2.6.3/specs
  270.   gcc driver version 2.7.2 executing gcc version 2.6.3
  271.  
  272.  
  273.  
  274.  
  275.  
  276.   o  /usr/target/(bin|lib|include)/.  If you have multiple targets
  277.      installed (for example, a.out and elf, or a cross-compiler of some
  278.      sort, the libraries, binutils (as, ld and so on) and header files
  279.      for the non-native target(s) can be found here.  Even if you only
  280.      have one kind of gcc installed you might find anyway that various
  281.      bits for it are kept here.  If not, they're in
  282.      /usr/(bin|lib|include).
  283.  
  284.   o  /lib/,/usr/lib and others are library directories for the native
  285.      system.  You will also need /lib/cpp for many applications (X makes
  286.      quite a lot of use of it) --- either copy it from /usr/lib/gcc-
  287.      lib/target/version/ or make a symlink pointing there.
  288.  
  289.  
  290.  
  291.  
  292.   3.3.  Where are the header files?
  293.  
  294.   Apart from whatever you install yourself under /usr/local/include,
  295.   there are three main sources of header files in Linux:
  296.  
  297.  
  298.   o  Most of /usr/include/ and its subdirectories are supplied with the
  299.      libc binary package from H J Lu.  I say `most' because you may also
  300.      have files from other sources (curses and dbm libraries, for
  301.      example) in here, especially if you are using the newest libc
  302.      distribution (which doesn't come with curses or dbm, unlike the
  303.      older ones).
  304.  
  305.  
  306.  
  307.  
  308.   o  /usr/include/linux and /usr/include/asm (for the files <linux/*.h>
  309.      and <asm/*.h>) should be symbolic links to the directories
  310.      linux/include/linux and linux/include/asm in the kernel source
  311.      distribution.  You need to install these if you plan to do any non-
  312.      trivial development; they are not just there for compiling the
  313.      kernel.
  314.  
  315.      You might find also that you need to do make config in the kernel
  316.      directory after unpacking the sources.  Many files depend on
  317.      <linux/autoconf.h> which otherwise may not exist, and in some
  318.      kernel versions asm is a symbolic link itself and only created at
  319.      make config time.
  320.  
  321.      So, if you unpack your kernel sources under /usr/src/linux, that's
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.   $ cd /usr/src/linux
  332.   $ su
  333.   # make config
  334.   [answer the questions.  Unless you're going to go on and build the kernel
  335.   it doesn't matter _too_ much what you say]
  336.   # cd /usr/include
  337.   # ln -s ../src/linux/include/linux .
  338.   # ln -s ../src/linux/include/asm .
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.   o  Files such as <float.h>, <limits.h>, <varargs.h>, <stdarg.h> and
  351.      <stddef.h> vary according to the compiler version, so are found in
  352.      /usr/lib/gcc-lib/i486-box-linux/2.7.2/include/ and places of that
  353.      ilk.
  354.  
  355.  
  356.   3.4.  Building cross compilers
  357.  
  358.   3.4.1.  Linux as the target platform
  359.  
  360.   Assuming you have obtained the source code to gcc, usually you can
  361.   just follow the instructions given in the INSTALL file for GCC.  A
  362.   configure --target=i486-linux --host=XXX on platform XXX followed by a
  363.   make should do the trick.  Note that you will need the Linux includes,
  364.   the kernel includes, and also to build the cross assembler and cross
  365.   linker from the sources in
  366.   <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/>.
  367.  
  368.  
  369.   3.4.2.  Linux as the source platform, MSDOS as the target
  370.  
  371.   Ugh.  Apparently this is somewhat possible by using the "emx" package
  372.   or the "go" extender.  Please look at
  373.   <ftp://sunsite.unc.edu/pub/Linux/devel/msdos>.
  374.  
  375.   I have not tested this and cannot vouch for its abilities.
  376.  
  377.  
  378.  
  379.   4.  Porting and Compiling
  380.  
  381.   4.1.  Automatically defined symbols
  382.  
  383.   You can find out what symbols your version of gcc defines
  384.   automatically by running it with the -v switch.  For example, mine
  385.   does:
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.   $ echo 'main(){printf("hello world\n");}' | gcc -E -v -
  398.   Reading specs from /usr/lib/gcc-lib/i486-box-linux/2.7.2/specs
  399.   gcc version 2.7.2
  400.    /usr/lib/gcc-lib/i486-box-linux/2.7.2/cpp -lang-c -v -undef
  401.   -D__GNUC__=2 -D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux
  402.   -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386
  403.   -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386)
  404.   -Amachine(i386) -D__i486__ -
  405.  
  406.  
  407.  
  408.  
  409.   If you are writing code that uses Linux-specific features, it is a
  410.   good idea to enclose the nonportable bits in
  411.  
  412.  
  413.  
  414.        #ifdef __linux__
  415.        /* ... funky stuff ... */
  416.        #endif /* linux */
  417.  
  418.  
  419.  
  420.  
  421.   Use __linux__ for this purpose, not linux.  Although the latter is
  422.   defined, it is not POSIX compliant.
  423.  
  424.  
  425.  
  426.   4.2.  Compiler invocation
  427.  
  428.   The documentation for compiler switches is the gcc info page (in
  429.   Emacs, use C-h i then select the `gcc' option).  Your distributor may
  430.   not have packed this with your system, or you may have an old version;
  431.   the best thing to do in this case is to download the gcc source
  432.   archive from  <ftp://prep.ai.mit.edu/pub/gnu> or one of its mirrors,
  433.   and copy them out of it.
  434.  
  435.   The gcc manual page (gcc.1) is, generally speaking, out of date.  It
  436.   will warn you of this when you try to look at it.
  437.  
  438.  
  439.   4.2.1.
  440.  
  441.   Compiler flags
  442.  
  443.   gcc can be made to optimize its output code by adding -On to its
  444.   command line, where n is an optional small integer.  Meaningful values
  445.   of n, and their exact effect, vary according to the exact version, but
  446.   typically it ranges from 0 (no optimization) to 2 (lots) or 3 (lots
  447.   and lots).
  448.  
  449.   Internally, gcc translates these to a series of -f and -m options.
  450.   You can see exactly which -O levels map to which options by running
  451.   gcc with the -v flag and the (undocumented) -Q flag.  For example, for
  452.   -O2, mine says
  453.  
  454.  
  455.  
  456.        enabled: -fdefer-pop -fcse-follow-jumps -fcse-skip-blocks
  457.        -fexpensive-optimizations
  458.                 -fthread-jumps -fpeephole -fforce-mem -ffunction-cse -finline
  459.                 -fcaller-saves -fpcc-struct-return -frerun-cse-after-loop
  460.                 -fcommon -fgnu-linker -m80387 -mhard-float -mno-soft-float
  461.                 -mno-386 -m486 -mieee-fp -mfp-ret-in-387
  462.  
  463.   Using an optimization level higher than your compiler supports (e.g.
  464.   -O6) will have exactly the same effect as using the highest level that
  465.   it does support.  Distributing code which is set to compile this way
  466.   is a poor idea though --- if further optimisations are incorporated
  467.   into future versions, you (or your users) may find that they break
  468.   your code.
  469.  
  470.  
  471.   Users of gcc 2.7.0 thru 2.7.2 should note that there is a bug in -O2
  472.   on these.  Specifically, strength reduction doesn't work.  A patch can
  473.   be had to fix this if you feel like recompiling gcc, otherwise make
  474.   sure that you always compile with -fno-strength-reduce
  475.  
  476.  
  477.  
  478.   4.2.1.1.  Processor-specific
  479.  
  480.   There are other -m flags which aren't turned on by any variety of -O
  481.   but are nevertheless useful.  Chief among these are -m386 and -m486,
  482.   which tell gcc to favour the 386 or 486 respectively.  Code compiled
  483.   with one of these will still work on the other; 486 code is bigger,
  484.   but otherwise not slower on the 386.
  485.  
  486.   There is currently no -mpentium or -m586.  Linus suggests using -m486
  487.   -malign-loops=2 -malign-jumps=2 -malign-functions=2, to get 486 code
  488.   optimisations but without the big gaps for alignment (which the
  489.   pentium doesn't need).  Michael Meissner (of Cygnus) says
  490.  
  491.  
  492.        My hunch is that -mno-strength-reduce also results in faster
  493.        code on the x86 (note, I'm not talking about the strength
  494.        reduction bug, which is another issue).  This is because the
  495.        x86 is rather register starved (and GCC's method of grouping
  496.        registers into spill registers vs. other registers doesn't
  497.        help either).  Strength reduction typically results in using
  498.        additional registers to replace multiplications with addi-
  499.        tion.  I also suspect -fcaller-saves may also be a loss.
  500.  
  501.  
  502.  
  503.        Another hunch is that -fomit-frame-pointer might or might
  504.        not be a win.  On the one hand, it can mean that another
  505.        register is available for allocation.  On the other hand,
  506.        the way the x86 encodes its instruction set, means that
  507.        stack relative addresses take more space instead of frame
  508.        relative addresses, which means slightly less Icache avail-
  509.        ble to the program.  Also, -fomit-frame-pointer, means that
  510.        the compiler has to constantly adjust the stack pointer
  511.        after calls, while with a frame, it can let the stack accu-
  512.        mulate for a few calls.
  513.  
  514.  
  515.   The final word on this subject is from Linus again:
  516.  
  517.  
  518.        Note that if you want to get optimal performance, don't
  519.        believe me: test.  There are lots of gcc compiler switches,
  520.        and it may be that a particular set gives the best optimiza-
  521.        tions for you.
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.   4.2.2.
  530.  
  531.  
  532.  
  533.  
  534.   Internal compiler error: cc1 got fatal signal 11
  535.  
  536.   Signal 11 is SIGSEGV, or `segmentation violation'.  Usually it means
  537.   that the program got its pointers confused and tried to write to
  538.   memory it didn't own.  So, it could be a gcc bug.
  539.  
  540.   gcc is however, a well tested and reliable piece of software, for the
  541.   most part.  It also uses a large number of complex data structures,
  542.   and an awful lot of pointers.  In short, it's the pickiest RAM tester
  543.   commonly available.  If you can't duplicate the bug --- if it doesn't
  544.   stop in the same place when you restart the compilation --- it's
  545.   almost certainly a problem with your hardware (CPU, memory,
  546.   motherboard or cache).  Don't claim it as a bug because your computer
  547.   passes the power-on checks or runs Windows ok or whatever; these
  548.   `tests' are commonly and rightly held to be worthless.  And don't
  549.   claim it's a bug because a kernel compile always stops during `make
  550.   zImage' --- of course it will!  `make zImage' is probably compiling
  551.   over 200 files; we're looking for a slightly smaller place than that.
  552.  
  553.  
  554.   If you can duplicate the bug, and (better) can produce a short program
  555.   that exhibits it, you can submit it as a bug report to the FSF, or to
  556.   the linux-gcc mailing list.  See the gcc documentation for details of
  557.   exactly what information they need.
  558.  
  559.  
  560.  
  561.   4.3.  Portability
  562.  
  563.   It has been said that, these days, if something hasn't been ported to
  564.   Linux then it is not worth having :-)
  565.  
  566.   Seriously though, in general only minor changes are needed to the
  567.   sources to get over Linux's 100% POSIX compliance. It is also
  568.   worthwhile passing back any changes to authors of the code such that
  569.   in the future only `make' need be called to provide a working
  570.   executable.
  571.  
  572.  
  573.   4.3.1.  BSDisms (including bsd_ioctl , daemon  and <sgtty.h> )
  574.  
  575.   You can compile your program with -I/usr/include/bsd and link it with
  576.   -lbsd (i.e. add -I/usr/include/bsd to CFLAGS and -lbsd to the LDFLAGS
  577.   line in your Makefile). There is no need to add -D__USE_BSD_SIGNAL any
  578.   more if you want BSD type signal behavior, as you get this
  579.   automatically when you have -I/usr/include/bsd and include <signal.h>.
  580.  
  581.  
  582.   4.3.2.
  583.  
  584.  
  585.  
  586.  
  587.   `Missing' signals ( SIGBUS , SIGEMT , SIGIOT , SIGTRAP , SIGSYS  etc)
  588.  
  589.   Linux is POSIX compliant.  These are not POSIX-defined signals ---
  590.   ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990), paragraph B.3.3.1.1 sez:
  591.  
  592.  
  593.        ``The signals SIGBUS, SIGEMT, SIGIOT, SIGTRAP, and SIGSYS
  594.        were omitted from POSIX.1 because their behavior is
  595.   implementation dependent and could not be adequately catego-
  596.   rized.  Conforming implementations may deliver these sig-
  597.   nals, but must document the circumstances under which they
  598.   are delivered and note any restrictions concerning their
  599.   delivery.''
  600.  
  601.  
  602.  
  603.   The cheap and cheesy way to fix this is to redefine these signals to
  604.   SIGUNUSED.  The correct way is to bracket the code that handles them
  605.   with appropriate #ifdefs:
  606.  
  607.  
  608.  
  609.        #ifdef SIGSYS
  610.        /* ... non-posix SIGSYS code here .... */
  611.        #endif
  612.  
  613.  
  614.  
  615.  
  616.  
  617.   4.3.3.  K & R Code
  618.  
  619.   GCC is an ANSI compiler; much existing code is not ANSI.  There's
  620.   really not much that can be done about this, except to add
  621.   -traditional to the compiler flags.  There is a certain amount of
  622.   finer-grained control over which varieties of brain damage to emulate;
  623.   consult the gcc info page.
  624.  
  625.   Note that -traditional has effects beyond just changing the language
  626.   that gcc accepts.  For example, it turns on -fwritable-strings, which
  627.   moves string constants into data space (from text space, where they
  628.   cannot be written to).  This increases the memory footprint of the
  629.   program.
  630.  
  631.  
  632.   4.3.4.
  633.  
  634.   Preprocessor symbols conflict with prototypes in the code
  635.  
  636.   One of the most frequent problems is that some common functions are
  637.   defined as macros in Linux's header files and the preprocessor will
  638.   refuse to parse similar prototype definitions in the code. Common ones
  639.   are atoi() and atol().
  640.  
  641.  
  642.   4.3.5.  sprintf()
  643.  
  644.   Something to be aware of, especially when porting from SunOS, is that
  645.   sprintf(string, fmt, ...) returns a pointer to string on many unices,
  646.   whereas Linux (following ANSI) returns the number of characters which
  647.   were put into the string.
  648.  
  649.  
  650.   4.3.6.  FD_*  stuff ?
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.   fcntl  and friends.  Where are the definitions of
  658.  
  659.   In <sys/time.h>.  If you are using fcntl you probably want to include
  660.   <unistd.h> too, for the actual prototype.
  661.   Generally speaking, the manual page for a function lists the necessary
  662.   #includes in its SYNOPSIS section.
  663.  
  664.  
  665.  
  666.   4.3.7.  The select()  timeout.  Programs start busy-waiting.
  667.  
  668.   Once upon a time, the timeout parameter to select() was used read-
  669.   only.  Even then, manual pages warned:
  670.  
  671.  
  672.        select() should probably return the time remaining from the
  673.        original timeout, if any, by modifying the time value in
  674.        place.  This may be implemented in future versions of the
  675.        system.  Thus, it is unwise to assume that the timeout
  676.        pointer will be unmodified by the select() call.
  677.  
  678.  
  679.   The future has arrived!  At least, it has here.  On return from a
  680.   select(), the timeout argument will be set to the remaining time that
  681.   it would have waited had data not arrived.  If no data had arrived,
  682.   this will be zero, and future calls using the same timeout structure
  683.   will immediately return.
  684.  
  685.   To fix, put the timeout value into that structure every time you call
  686.   select().  Change code like
  687.  
  688.  
  689.              struct timeval timeout;
  690.              timeout.tv_sec = 1; timeout.tv_usec = 0;
  691.              while (some_condition)
  692.                    select(n,readfds,writefds,exceptfds,&timeout);
  693.  
  694.  
  695.  
  696.  
  697.   to, say,
  698.  
  699.  
  700.              struct timeval timeout;
  701.              while (some_condition) {
  702.                    timeout.tv_sec = 1; timeout.tv_usec = 0;
  703.                    select(n,readfds,writefds,exceptfds,&timeout);
  704.              }
  705.  
  706.  
  707.  
  708.  
  709.   Some versions of Mosaic were at one time notable for this problem.
  710.   The speed of the spinning globe animation was inversely related to the
  711.   speed that the data was coming in from the network at!
  712.  
  713.  
  714.   4.3.8.
  715.  
  716.   Interrupted system calls.
  717.  
  718.   4.3.8.1.  Symptom:
  719.  
  720.   When a program is stopped using Ctrl-Z and then restarted - or in
  721.   other situations that generate signals: Ctrl-C interruption,
  722.   termination of a child process etc. - it complains about "interrupted
  723.   system call" or "write: unknown error" or things like that.
  724.  
  725.  
  726.  
  727.   4.3.8.2.  Problem:
  728.  
  729.   POSIX systems check for signals a bit more often than some older
  730.   unices.  Linux may execute signal handlers ---
  731.  
  732.  
  733.   o  asynchronously (at a timer tick)
  734.  
  735.   o  on return from any system call
  736.  
  737.   o  during the execution of the following system calls: select(),
  738.      pause(), connect(), accept(), read() on terminals, sockets, pipes
  739.      or files in /proc, write() on terminals, sockets, pipes or the line
  740.      printer, open() on FIFOs, PTYs or serial lines, ioctl() on
  741.      terminals, fcntl() with command F_SETLKW, wait4(), syslog(), any
  742.      TCP or NFS operations.
  743.  
  744.   For other operating systems you may have to include the system calls
  745.   creat(), close(), getmsg(), putmsg(), msgrcv(), msgsnd(), recv(),
  746.   send(), wait(), waitpid(), wait3(), tcdrain(), sigpause(), semop() to
  747.   this list.
  748.  
  749.  
  750.   If a signal (that the program has installed a handler for) occurs
  751.   during a system call, the handler is called.  When the handler returns
  752.   (to the system call) it detects that it was interrupted, and
  753.   immediately returns with -1 and errno = EINTR.  The program is not
  754.   expecting that to happen, so bottles out.
  755.  
  756.   You may choose between two fixes.
  757.  
  758.   (1) For every signal handler that you install, add SA_RESTART to the
  759.   sigaction flags. For example, change
  760.  
  761.  
  762.  
  763.          signal (sig_nr, my_signal_handler);
  764.  
  765.  
  766.  
  767.  
  768.   to
  769.  
  770.  
  771.          signal (sig_nr, my_signal_handler);
  772.          { struct sigaction sa;
  773.            sigaction (sig_nr, (struct sigaction *)0, &sa);
  774.        #ifdef SA_RESTART
  775.            sa.sa_flags |= SA_RESTART;
  776.        #endif
  777.        #ifdef SA_INTERRUPT
  778.            sa.sa_flags &= ~ SA_INTERRUPT;
  779.        #endif
  780.            sigaction (sig_nr, &sa, (struct sigaction *)0);
  781.          }
  782.  
  783.  
  784.  
  785.  
  786.   Note that while this applies to most system calls, you must still
  787.   check for EINTR yourself on read(), write(), ioctl(), select(),
  788.   pause() and connect().  See below.
  789.  
  790.   (2) Check for EINTR explicitly, yourself:
  791.  
  792.  
  793.   Here are two examples for read() and ioctl(),
  794.  
  795.   Original piece of code using read()
  796.  
  797.  
  798.  
  799.        int result;
  800.        while (len > 0) {
  801.          result = read(fd,buffer,len);
  802.          if (result < 0) break;
  803.          buffer += result; len -= result;
  804.        }
  805.  
  806.  
  807.  
  808.  
  809.   becomes
  810.  
  811.  
  812.  
  813.        int result;
  814.        while (len > 0) {
  815.          result = read(fd,buffer,len);
  816.          if (result < 0) { if (errno != EINTR) break; }
  817.          else { buffer += result; len -= result; }
  818.        }
  819.  
  820.  
  821.  
  822.  
  823.   and a piece of code using ioctl()
  824.  
  825.  
  826.  
  827.        int result;
  828.        result = ioctl(fd,cmd,addr);
  829.  
  830.  
  831.  
  832.  
  833.   becomes
  834.  
  835.  
  836.        int result;
  837.        do { result = ioctl(fd,cmd,addr); }
  838.        while ((result == -1) && (errno == EINTR));
  839.  
  840.  
  841.  
  842.  
  843.   Note that in some versions of BSD Unix the default behaviour is to
  844.   restart system calls. To get system calls interrupted you have to use
  845.   the SV_INTERRUPT or SA_INTERRUPT flag.
  846.  
  847.  
  848.  
  849.   4.3.9.
  850.  
  851.  
  852.  
  853.   Writable strings (program seg faults randomly)
  854.  
  855.   GCC has an optimistic view of its users, believing that they intend
  856.   string constants to be exactly that --- constant.  Thus, it stores
  857.   them in the text (code) area of the program, where they can be paged
  858.   in and out from the program's disk image (instead of taking up
  859.   swapspace), and any attempt to rewrite them will cause a segmentation
  860.   fault.  This is a feature!
  861.  
  862.   It may cause a problem for old programs that, for example, call
  863.   mktemp() with a string constant as argument.  mktemp() attempts to
  864.   rewrite its argument in place.
  865.  
  866.   To fix, either (a) compile with -fwritable-strings, to get gcc to put
  867.   constants in data space, or (b) rewrite the offending parts to
  868.   allocate a non-constant string and strcpy the data into it before
  869.   calling.
  870.  
  871.  
  872.   4.3.10.  Why does the execl()  call fail?
  873.  
  874.   Because you're calling it wrong.  The first argument to execl is the
  875.   program that you want to run.  The second and subsequent arguments
  876.   become the argv array of the program you're calling.  Remember:
  877.   argv[0] is traditionally set even when a program is run with `no'
  878.   arguments.  So, you should be writing
  879.  
  880.  
  881.  
  882.        execl("/bin/ls","ls",NULL);
  883.  
  884.  
  885.  
  886.  
  887.   not just
  888.  
  889.  
  890.        execl("/bin/ls", NULL);
  891.  
  892.  
  893.  
  894.  
  895.  
  896.   Executing the program with no arguments at all is construed as an
  897.   invitation to print out its dynamic library dependencies, at least
  898.   using a.out.  ELF does things differently.
  899.  
  900.  
  901.   (If you want this library information, there are simpler interfaces;
  902.   see the section on dynamic loading, or the manual page for ldd).
  903.  
  904.  
  905.  
  906.   5.  Debugging and Profiling
  907.  
  908.   5.1.  Preventative maintenance (lint)
  909.  
  910.   There is no widely-used lint for Linux, as most people are satisfied
  911.   with the warnings that gcc can generate.  Probably the most useful is
  912.   the -Wall switch --- this stands for `Warnings, all' but probably has
  913.   more mnemonic value if thought of as the thing you bang your head
  914.   against.
  915.  
  916.   There is a public domain lint available from
  917.   <ftp://larch.lcs.mit.edu/pub/Larch/lclint>.  I don't know how good it
  918.   is.
  919.  
  920.  
  921.   5.2.  Debugging
  922.  
  923.  
  924.  
  925.   5.2.1.
  926.  
  927.  
  928.   How do I get debugging information into a program ?
  929.  
  930.   You need to compile and link all its bits with the -g switch, and
  931.   without the -fomit-frame-pointer switch.  Actually, you don't need to
  932.   recompile all of it, just the bits you're interested in debugging.
  933.  
  934.  
  935.   On a.out configurations the shared libraries are compiled with -fomit-
  936.   frame-pointer, which gdb won't get on with.  Giving the -g option when
  937.   you link should imply static linking; this is why.
  938.  
  939.  
  940.   If the linker fails with a message about not finding libg.a, you don't
  941.   have /usr/lib/libg.a, which is the special debugging-enabled C
  942.   library.  It may be supplied in the libc binary package, or (in newer
  943.   C library versions) you may need to get the libc source code and build
  944.   it yourself.  You don't actually need it though; you can get enough
  945.   information for most purposes simply by symlinking it to
  946.   /usr/lib/libc.a
  947.  
  948.  
  949.   5.2.1.1.  How do I get it out again?
  950.  
  951.   A lot of GNU software comes set up to compile and link with -g,
  952.   causing it to make very big (and often static) executables.  This is
  953.   not really such a hot idea.
  954.  
  955.  
  956.   If the program has an autoconf generated configure script, you can
  957.   usually turn off debugging information by doing ./configure CFLAGS= or
  958.   ./configure CFLAGS=-O2.  Otherwise, check the Makefile.  Of course, if
  959.   you're using ELF, the program is dynamically linked regardless of the
  960.   -g setting, so you can just strip it.
  961.  
  962.  
  963.  
  964.   5.2.2.  Available software
  965.  
  966.   Most people use gdb, which you can get in source form from GNU archive
  967.   sites <ftp://prep.ai.mit.edu/pub/gnu>, or as a binary from tsx-11
  968.   <ftp://tsx-11.mit.edu/pub/linux/packages/GCC> or sunsite.  xxgdb is an
  969.   X debugger based on this (i.e. you need gdb installed first). The
  970.   source may be found at  <ftp://ftp.x.org/contrib/xxgdb-1.08.tar.gz>
  971.  
  972.   Also, the UPS debugger has been ported by Rick Sladkey. It runs under
  973.   X as well, but unlike xxgdb, it is not merely an X front end for a
  974.   text based debugger. It has quite a number of nice features, and if
  975.   you spend any time debugging stuff, you probably should check it out.
  976.   The Linux precompiled version and patches for the stock UPS sources
  977.   can be found in  <ftp://sunsite.unc.edu/pub/Linux/devel/debuggers/>,
  978.   and the original source at
  979.   <ftp://ftp.x.org/contrib/ups-2.45.2.tar.Z>.
  980.  
  981.   Another tool you might find useful for debugging is `strace', which
  982.   displays the system calls that a process makes.  It has a multiplicity
  983.   of other uses too, including figuring out what pathnames were compiled
  984.   into binaries that you don't have the source for, exacerbating race
  985.   conditions in programs that you suspect contain them, and generally
  986.   learning how things work.  The latest version of strace (currently
  987.   3.0.8) can be found at  <ftp://ftp.std.com/pub/jrs/>.
  988.  
  989.  
  990.  
  991.   5.2.3.  Background (daemon) programs
  992.  
  993.   Daemon programs typically execute fork() early, and terminate the
  994.   parent.  This makes for a short debugging session.
  995.  
  996.  
  997.   The simplest way to get around this is to set a breakpoint for fork,
  998.   and when the program stops, force it to return 0.
  999.  
  1000.  
  1001.  
  1002.        (gdb) list
  1003.        1       #include <stdio.h>
  1004.        2
  1005.        3       main()
  1006.        4       {
  1007.        5         if(fork()==0) printf("child\n");
  1008.        6         else printf("parent\n");
  1009.        7       }
  1010.        (gdb) break fork
  1011.        Breakpoint 1 at 0x80003b8
  1012.        (gdb) run
  1013.        Starting program: /home/dan/src/hello/./fork
  1014.        Breakpoint 1 at 0x400177c4
  1015.  
  1016.        Breakpoint 1, 0x400177c4 in fork ()
  1017.        (gdb) return 0
  1018.        Make selected stack frame return now? (y or n) y
  1019.        #0  0x80004a8 in main ()
  1020.            at fork.c:5
  1021.        5         if(fork()==0) printf("child\n");
  1022.        (gdb) next
  1023.        Single stepping until exit from function fork,
  1024.        which has no line number information.
  1025.        child
  1026.        7       }
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.   5.2.4.  Core files
  1033.  
  1034.   When Linux boots it is usually configured not to produce core files.
  1035.   If you like them, use your shell's builtin command to re-enable them:
  1036.   for C-shell compatibles (e.g. tcsh) this is
  1037.  
  1038.  
  1039.        % limit core unlimited
  1040.  
  1041.  
  1042.  
  1043.  
  1044.   while Bourne-like shells (sh, bash, zsh, pdksh) use
  1045.  
  1046.  
  1047.        $ ulimit -c unlimited
  1048.  
  1049.  
  1050.  
  1051.  
  1052.   If you want a bit more versatility in your core file naming (for
  1053.   example, if you're trying to conduct a post-mortem using a debugger
  1054.   that's buggy itself) you can make a simple mod to your kernel.  Look
  1055.   for the code in fs/binfmt_aout.c and fs/binfmt_elf.c (in newer
  1056.   kernels, you'll have to grep around a little in older ones) that says
  1057.                memcpy(corefile,"core.",5);
  1058.        #if 0
  1059.                memcpy(corefile+5,current->comm,sizeof(current->comm));
  1060.        #else
  1061.                corefile[4] = '\0';
  1062.        #endif
  1063.  
  1064.  
  1065.  
  1066.  
  1067.   and change the 0s to 1s.
  1068.  
  1069.  
  1070.   5.3.  Profiling
  1071.  
  1072.   Profiling is a way to examine which bits of a program are called most
  1073.   often or run for longest. It is a good way to optimize code and look
  1074.   at where time is being wasted.  You must compile all object files that
  1075.   you require timing information for with -p, and to make sense of the
  1076.   output file you will also need gprof (from the binutils package).  See
  1077.   the gprof manual page for details.
  1078.  
  1079.  
  1080.  
  1081.   6.  Linking
  1082.  
  1083.   Between the two incompatible binary formats, the static vs shared
  1084.   library distinction, and the overloading of the verb `link' to mean
  1085.   both `what happens after compilation' and `what happens when a
  1086.   compiled program is invoked' (and, actually, the overloading of the
  1087.   word `load' in a comparable but opposite sense), this section is
  1088.   complicated.  Little of it is much more complicated than that
  1089.   sentence, though, so don't worry too much about it.
  1090.  
  1091.  
  1092.   To alleviate the confusion somewhat, we refer to what happens at
  1093.   runtime as `dynamic loading' and cover it in the next section.  You
  1094.   will also see it described as `dynamic linking', but not here.  This
  1095.   section, then, is exclusively concerned with the kind of linking that
  1096.   happens at the end of a compilation.
  1097.  
  1098.  
  1099.   6.1.  Shared vs static libraries
  1100.  
  1101.   The last stage of building a program is to `link' it; to join all the
  1102.   pieces of it together and see what is missing.  Obviously there are
  1103.   some things that many programs will want to do --- open files, for
  1104.   example, and the pieces that do these things are provided for you in
  1105.   the form of libraries.  On the average Linux system these can be found
  1106.   in /lib and /usr/lib/, among other places.
  1107.  
  1108.  
  1109.  
  1110.  
  1111.   When using a static library, the linker finds the bits that the
  1112.   program modules need, and physically copies them into the executable
  1113.   output file that it generates.  For shared libraries, it doesn't ---
  1114.   instead it leaves a note in the output saying `when this program is
  1115.   run, it will first have to load this library'.  Obviously shared
  1116.   libraries tend to make for smaller executables; they also use less
  1117.   memory and mean that less disk space is used.  The default behaviour
  1118.   of Linux is to link shared if it can find the shared libraries, static
  1119.   otherwise.  If you're getting static binaries when you want shared,
  1120.   check that the shared library files (*.sa for a.out, *.so for ELF) are
  1121.   where they should be, and are readable.
  1122.  
  1123.   On Linux, static libraries have names like libname.a, while shared
  1124.   libraries are called libname.so.x.y.z where x.y.z is some form of
  1125.   version number.  Shared libraries often also have links pointing to
  1126.   them, which are important, and (on a.out configurations) associated
  1127.   .sa files.  The standard libraries come in both shared and static
  1128.   formats.
  1129.  
  1130.   You can find out what shared libraries a program requires by using ldd
  1131.   (List Dynamic Dependencies)
  1132.  
  1133.  
  1134.        $ ldd /usr/bin/lynx
  1135.                libncurses.so.1 => /usr/lib/libncurses.so.1.9.6
  1136.                libc.so.5 => /lib/libc.so.5.2.18
  1137.  
  1138.  
  1139.  
  1140.  
  1141.   This shows that on my system the WWW browser `lynx' depends on the
  1142.   presence of libc.so.5 (the C library) and libncurses.so.1 (used for
  1143.   terminal control).  If a program has no dependencies, ldd will say
  1144.   `statically linked' or `statically linked (ELF)'.
  1145.  
  1146.  
  1147.   6.2.
  1148.  
  1149.  
  1150.   Interrogating libraries (`which library is sin()  in?')
  1151.  
  1152.   nm libraryname should list all the symbols that libraryname has
  1153.   references to.  It works on both static and shared libraries.  Suppose
  1154.   that you want to know where tcgetattr() is defined: you might do
  1155.  
  1156.  
  1157.  
  1158.        $ nm libncurses.so.1 |grep tcget
  1159.                 U tcgetattr
  1160.  
  1161.  
  1162.  
  1163.  
  1164.   The U stands for `undefined' --- it shows that the ncurses library
  1165.   uses but does not define it.  You could also do
  1166.  
  1167.  
  1168.  
  1169.        $ nm libc.so.5 | grep tcget
  1170.        00010fe8 T __tcgetattr
  1171.        00010fe8 W tcgetattr
  1172.        00068718 T tcgetpgrp
  1173.  
  1174.  
  1175.  
  1176.  
  1177.   The `W' stands for `weak', which means that the symbol is defined, but
  1178.   in such a way that it can be overridden by another definition in a
  1179.   different library.  A straightforward `normal' definition (such as the
  1180.   one for tcgetpgrp) is marked by a `T'
  1181.  
  1182.  
  1183.  
  1184.   The short answer to the question in the title, by the way, is
  1185.   libm.(so|a).  All the functions defined in <math.h> are kept in the
  1186.   maths library; thus you need to link with -lm when using any of them.
  1187.  
  1188.  
  1189.   6.3.  Finding files
  1190.  
  1191.   ld: Output file requires shared library `libfoo.so.1`
  1192.  
  1193.  
  1194.   The file search strategy of ld and friends varies according to
  1195.   version, but the only default you can reasonably assume is /usr/lib.
  1196.   If you want libraries elsewhere to be searched, specify their
  1197.   directories with the -L option to gcc or ld.
  1198.  
  1199.  
  1200.   If that doesn't help, check that you have the right file in that
  1201.   place.  For a.out, linking with -lfoo makes ld look for libfoo.sa
  1202.   (shared stubs), and if unsuccessful then for libfoo.a (static).  For
  1203.   ELF, it looks for libfoo.so then libfoo.a.  libfoo.so is usually a
  1204.   symbolic link to libfoo.so.x.
  1205.  
  1206.  
  1207.  
  1208.   6.4.  Building your own libraries
  1209.  
  1210.   6.4.1.  Version control
  1211.  
  1212.   As any other program, libraries tend to have bugs which get fixed over
  1213.   time.  They also may introduce new features, change the effect of
  1214.   existing ones, or remove old ones.  This could be a problem for
  1215.   programs using them; what if it was depending on that old feature?
  1216.  
  1217.   So, we introduce library versioning.  We categorise the changes that
  1218.   might be made to a library as `minor' or `major', and we rule that a
  1219.   `minor' change is not allowed to break old programs that are using the
  1220.   library.  You can tell the version of a library by looking at its
  1221.   filename (actually, this is, strictly speaking, a lie for ELF; keep
  1222.   reading to find out why) : libfoo.so.1.2 has major version 1, minor
  1223.   version 2.  The minor version number can be more or less anything ---
  1224.   libc puts a `patchlevel' in it, giving library names like
  1225.   libc.so.5.2.18, and it's also reasonable to put letters, underscores,
  1226.   or more or less any printable ASCII in it.
  1227.  
  1228.   One of the major differences between ELF and a.out format is in
  1229.   building shared libraries.  We look at ELF first, because it's
  1230.   simpler.
  1231.  
  1232.  
  1233.   6.4.2.  ELF?  What is it then, anyway?
  1234.  
  1235.   ELF (Executable and Linking Format) is a binary format originally
  1236.   developed by USL (UNIX System Laboratories) and currently used in
  1237.   Solaris and System V Release 4.  Because of its increased flexibility
  1238.   over the older a.out format that Linux was using, the GCC and C
  1239.   library developers decided last year to move to using ELF as the Linux
  1240.   standard binary format also.
  1241.  
  1242.  
  1243.   6.4.2.1.  Come again?
  1244.  
  1245.   This section is from the document '/news-archives/comp.sys.sun.misc'.
  1246.  
  1247.  
  1248.        ELF ("Executable Linking Format) is the "new, improved"
  1249.        object file format introduced in SVR4. ELF is much more pow-
  1250.        erful than straight COFF, in that it *is* user-extensible.
  1251.        ELF views an object-file as an arbitarily long list of sec-
  1252.        tions (rather than an array of fixed size entities), these
  1253.        sections, unlike in COFF, do not HAVE to be in a certain
  1254.        place and do not HAVE to come in any specific order etc.
  1255.   Users can add new sections to object-files if they wish to
  1256.   capture new data. ELF also has a far more powerful debugging
  1257.   format called DWARF (Debugging With Attribute Record Format)
  1258.   - not currently fully supported on linux (but work is under-
  1259.   way). A linked list of DWARF DIEs (or Debugging Information
  1260.   Entries) forms the .debug section in ELF. Instead of being a
  1261.   collection of small, fixed-size information records, DWARF
  1262.   DIEs each contain an arbitrarily long list of complex
  1263.   attributes and are written out as a scope-based tree of pro-
  1264.   gram data. DIEs can capture a large amount of information
  1265.   that the COFF .debug section simply couldn't (like C++
  1266.   inheritance graphs etc.).
  1267.  
  1268.  
  1269.  
  1270.        ELF files are accessed via the SVR4 (Solaris 2.0 ?) ELF
  1271.        access library, which provides an easy and fast interface to
  1272.        the more gory parts of ELF. One of the major boons in using
  1273.        the ELF access library is that you will never need to look
  1274.        at an ELF file qua. UNIX file, it is accessed as an Elf *,
  1275.        after an elf_open() call and from then on, you perform
  1276.        elf_foobar() calls on its components instead of messing
  1277.        about with its actual on-disk image (something many COFFers
  1278.        did with impunity).
  1279.  
  1280.  
  1281.   The case for/against ELF, and the necessary contortions to upgrade an
  1282.   a.out system to support it, are covered in the ELF-HOWTO and I don't
  1283.   propose to cut/paste them here.  The HOWTO should be available in the
  1284.   same place as you found this one.
  1285.  
  1286.  
  1287.   6.4.2.2.  ELF shared libraries
  1288.  
  1289.   To build libfoo.so as a shared library, the basic steps look like
  1290.   this:
  1291.  
  1292.  
  1293.  
  1294.        $ gcc -fPIC -c *.c
  1295.        $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
  1296.        $ ln -s libfoo.so.1.0 libfoo.so.1
  1297.        $ ln -s libfoo.so.1 libfoo.so
  1298.        $ LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ; export LD_LIBRARY_PATH
  1299.  
  1300.  
  1301.  
  1302.  
  1303.   This will generate a shared library called libfoo.so.1.0, and the
  1304.   appropriate links for ld (libfoo.so) and the dynamic loader
  1305.   (libfoo.so.1) to find it.  To test, we add the current directory to
  1306.   LD_LIBRARY_PATH.
  1307.  
  1308.  
  1309.   When you're happpy that the library works, you'll have to move it to,
  1310.   say, /usr/local/lib, and recreate the appropriate links.  The link
  1311.   from libfoo.so.1 to libfoo.so.1.0 is kept up to date by ldconfig,
  1312.   which on most systems is run as part of the boot process.  The
  1313.   libfoo.so link must be updated manually.  If you are scrupulous about
  1314.   upgrading all the parts of a library (e.g. the header files) at the
  1315.   same time, the simplest thing to do is make libfoo.so -> libfoo.so.1,
  1316.   so that ldconfig will keep both links current for you.  If you aren't,
  1317.   you're setting yourself up to have all kinds of weird things happen at
  1318.   a later date.  Don't say you weren't warned.
  1319.  
  1320.  
  1321.        $ su
  1322.        # cp libfoo.so.1.0 /usr/local/lib
  1323.        # /sbin/ldconfig
  1324.        # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.   6.4.2.3.
  1331.  
  1332.   Version numbering, sonames and symlinks
  1333.  
  1334.   Each library has a soname.  When the linker finds one of these in a
  1335.   library it is searching, it embeds the soname into the binary instead
  1336.   of the actual filename it is looking at.  At runtime, the dynamic
  1337.   loader will then search for a file with the name of the soname, not
  1338.   the library filename.  Thus a library called libfoo.so could have a
  1339.   soname libbar.so, and all programs linked to it would look for
  1340.   libbar.so instead when they started.
  1341.  
  1342.  
  1343.   This sounds like a pointless feature, but it is key to understanding
  1344.   how multiple versions of the same library can coexist on a system.
  1345.   The de facto naming standard for libraries in Linux is to call the
  1346.   library, say, libfoo.so.1.2, and give it a soname of libfoo.so.1.  If
  1347.   it's added to a `standard' library directory (e.g. /usr/lib), ldconfig
  1348.   will create a symlink libfoo.so.1 -> libfoo.so.1.2 so that the
  1349.   appropriate image is found at runtime.  You also need a link libfoo.so
  1350.   -> libfoo.so.1 so that ld will find the right soname to use at link
  1351.   time.
  1352.  
  1353.   So, when you fix bugs in the library, or add new functions (any
  1354.   changes that won't adversely affect existing programs), you rebuild
  1355.   it, keeping the soname as it was, and changing the filename.  When you
  1356.   make changes to the library that would break existing binaries, you
  1357.   simply increment the number in the soname --- in this case, call the
  1358.   new version libfoo.so.2.0, and give it a soname of libfoo.so.2.  Now
  1359.   switch the libfoo.so link to point to the new version and all's well
  1360.   with the world again.
  1361.  
  1362.   Note that you don't have to name libraries this way, but it's a good
  1363.   convention.  ELF gives you the flexibility to name libraries in ways
  1364.   that will confuse the pants off people, but that doesn't mean you have
  1365.   to use it.
  1366.  
  1367.   Executive summary: supposing that you observe the tradition that major
  1368.   upgrades may break compatibility, minor upgrades may not, then link
  1369.   with
  1370.  
  1371.  
  1372.  
  1373.        gcc -shared -Wl,-soname,libfoo.so.major -o libfoo.so.major.minor
  1374.  
  1375.  
  1376.  
  1377.  
  1378.   and everything will be all right.
  1379.  
  1380.  
  1381.   6.4.3.  a.out.  Ye olde traditional format
  1382.  
  1383.   The ease of building shared libraries is a major reason for upgrading
  1384.   to ELF.  That said, it's still possible in a.out.  Get
  1385.   <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.17.tar.gz>
  1386.   and read the 20 page document that you will find after unpacking it.
  1387.   I hate to be so transparently partisan, but it should be clear from
  1388.   context that I never bothered myself :-)
  1389.  
  1390.  
  1391.   6.4.3.1.
  1392.  
  1393.   ZMAGIC vs QMAGIC
  1394.  
  1395.   QMAGIC is an executable format just like the old a.out (also known as
  1396.   ZMAGIC) binaries, but which leaves the first page unmapped. This
  1397.   allows for easier NULL dereference trapping as no mapping exists in
  1398.   the range 0-4096. As a side effect your binaries are nominally smaller
  1399.   as well (by about 1K).
  1400.  
  1401.   Obsolescent linkers support ZMAGIC only, semi-obsolescent support both
  1402.   formats, and current versions support QMAGIC only.  This doesn't
  1403.   actually matter, though, as the kernel can still run both formats.
  1404.  
  1405.   Your `file' command should be able to identify whether a program is
  1406.   QMAGIC.
  1407.  
  1408.  
  1409.   6.4.3.2.  File Placement
  1410.  
  1411.   An a.out (DLL) shared library consists of two real files and a
  1412.   symlink.  For the `foo' library used throughout this document as an
  1413.   example, these files would be libfoo.sa and libfoo.so.1.2; the symlink
  1414.   would be libfoo.so.1 and would point at the latter of the files.  What
  1415.   are these for?
  1416.  
  1417.   At compile time, ld looks for libfoo.sa.  This is the `stub' file for
  1418.   the library, and contains all exported data and pointers to the
  1419.   functions required for run time linking.
  1420.  
  1421.   At run time, the dynamic loader looks for libfoo.so.1.  This is a
  1422.   symlink rather than a real file so that libraries can be updated with
  1423.   newer, bugfixed versions without crashing any application that was
  1424.   using the library at the time.  After the new version --- say,
  1425.   libfoo.so.1.3 --- is completely there, running ldconfig will switch
  1426.   the link to point to it in one atomic operation, leaving any program
  1427.   which had the old version still perfectly happy.
  1428.  
  1429.   DLL libraries (I know that's a tautology --- so sue me) often appear
  1430.   bigger than their static counterparts.  They reserve space for future
  1431.   expansion in the form of `holes' which can be made to take no disk
  1432.   space. A simple cp call or using the program makehole will achieve
  1433.   this.  You can also strip them after building, as the addresses are in
  1434.   fixed locations. Do not attempt to strip ELF libraries.
  1435.  
  1436.  
  1437.   6.4.3.3.  ``libc-lite''?
  1438.  
  1439.   A libc-lite is a light-weight version of the libc library built such
  1440.   that it will fit on a floppy and suffice for all of the most menial of
  1441.   UNIX tasks. It does not include curses, dbm, termcap etc code. If your
  1442.   /lib/libc.so.4 is linked to a lite lib, you are advised to replace it
  1443.   with a full version.
  1444.  
  1445.  
  1446.   6.4.4.  Linking: common problems
  1447.  
  1448.   Send me your linking problems!  I probably won't do anything about
  1449.   them, but I will write them up if I get enough ...
  1450.  
  1451.  
  1452.  
  1453.       Programs link static when you wanted them shared
  1454.  
  1455.  
  1456.  
  1457.         Check that you have the right links for ld to find each shared
  1458.         library.  For ELF this means a libfoo.so symlink to the image,
  1459.         for a.out a libfoo.sa file.  A lot of people had this problem
  1460.         after moving from ELF binutils 2.5 to 2.6 --- the earlier
  1461.         version searched more `intelligently' for shared libraries, so
  1462.         they hadn't created all the links.  The intelligent behaviour
  1463.         was removed for compatibility with other architectures, and
  1464.         because quite often it got its assumptions wrong and caused more
  1465.         trouble than it solved.
  1466.  
  1467.  
  1468.       The DLL tool `mkimage' fails to find libgcc, or
  1469.  
  1470.  
  1471.         As of libc.so.4.5.x and above, libgcc is no longer shared. Hence
  1472.         you must replace occurrences of `-lgcc' on the offending line
  1473.         with `gcc -print-libgcc-file-name` (complete with the
  1474.         backquotes).
  1475.  
  1476.         Also, delete all /usr/lib/libgcc* files.  This is important.
  1477.  
  1478.  
  1479.       __NEEDS_SHRLIB_libc_4 multiply defined messages
  1480.         are another consequence of the same problem.
  1481.  
  1482.  
  1483.       ``Assertion failure'' message when rebuilding a DLL ?
  1484.         This cryptic message most probably means that one of your jump
  1485.         table slots has overflowed because too little space has been
  1486.         reserved in the original jump.vars file.  You can locate the
  1487.         culprit(s) by running the `getsize' command provided in the
  1488.         tools-2.17.tar.gz package. Probably the only solution, though,
  1489.         is to bump the major version number of the library, forcing it
  1490.         to be backward incompatible.
  1491.  
  1492.  
  1493.       ld: output file needs shared library libc.so.4
  1494.         This usually happens when you are linking with libraries other
  1495.         than libc (e.g. X libraries), and use the -g switch on the link
  1496.         line without also using -static.
  1497.  
  1498.         The .sa stubs for the shared libraries usually have an undefined
  1499.         symbol _NEEDS_SHRLIB_libc_4 which gets resolved from the libc.sa
  1500.         stub.  However with -g you end up linking with libg.a or libc.a
  1501.         and thus this symbol never gets resolved, leading to the above
  1502.         error message.
  1503.  
  1504.         In conclusion, add -static when compiling with the -g flag, or
  1505.         don't link with -g.  Quite often you can get enough debugging
  1506.         information by compiling the individual files with -g, and
  1507.         linking without it.
  1508.  
  1509.  
  1510.  
  1511.  
  1512.   7.  Dynamic Loading
  1513.  
  1514.   This section is a tad short right now; it will be expanded over time
  1515.   as I gut the ELF howto
  1516.  
  1517.  
  1518.  
  1519.   7.1.  Concepts
  1520.  
  1521.   Linux has shared libraries, as you will by now be sick of hearing if
  1522.   you read the whole of the last section at a sitting.  Some of the
  1523.   matching-names-to-places work which was traditionally done at link
  1524.   time must be deferred to load time.
  1525.  
  1526.  
  1527.   7.2.  Error messages
  1528.  
  1529.   Send me your link errors!  I won't do anything about them, but I might
  1530.   write them up ...
  1531.  
  1532.  
  1533.  
  1534.       can't load library: /lib/libxxx.so, Incompatible version
  1535.         (a.out only) This means that you don't have the correct major
  1536.         version of the xxx library.  No, you can't just make a symlink
  1537.         to another version that you do have; if you are lucky this will
  1538.         cause your program to segfault.  Get the new version.  A similar
  1539.         situation with ELF will result in a message like
  1540.  
  1541.  
  1542.  
  1543.           ftp: can't load library 'libreadline.so.2'
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.      warning using incompatible library version xxx
  1550.         (a.out only) You have an older minor version of the library than
  1551.         the person who compiled the program used.  The program will
  1552.         still run.  Probably.  An upgrade wouldn't hurt, though.
  1553.  
  1554.  
  1555.  
  1556.   7.3.
  1557.  
  1558.   Controlling the operation of the dynamic loader
  1559.  
  1560.   There are a range of environment variables that the dynamic loader
  1561.   will respond to.  Most of these are more use to ldd than they are to
  1562.   the average user, and can most conveniently be set by running ldd with
  1563.   various switches.  They include
  1564.  
  1565.  
  1566.   o  LD_BIND_NOW --- normally, functions are not `looked up' in
  1567.      libraries until they are called.  Setting this flag causes all the
  1568.      lookups to happen when the library is loaded, giving a slower
  1569.      startup time.  It's useful when you want to test a program to make
  1570.      sure that everything is linked.
  1571.  
  1572.   o  LD_PRELOAD can be set to a file containing `overriding' function
  1573.      definitions.  For example, if you were testing memory allocation
  1574.      strategies, and wanted to replace `malloc', you could write your
  1575.      replacement routine, compile it into malloc.o and then
  1576.  
  1577.  
  1578.        $ LD_PRELOAD=malloc.o; export LD_PRELOAD
  1579.        $ some_test_program
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.   LD_ELF_PRELOAD and LD_AOUT_PRELOAD are similar, but only apply to the
  1586.   appropriate type of binary.  If LD_something_PRELOAD and LD_PRELOAD
  1587.   are set, the more specific one is used.
  1588.  
  1589.   o  LD_LIBRARY_PATH is a colon-separated list of directories in which
  1590.      to look for shared libraries.  It does not affect ld; it only has
  1591.      effect at runtime.  Also, it is disabled for programs that run
  1592.      setuid or setgid.  Again, LD_ELF_LIBRARY_PATH and
  1593.      LD_AOUT_LIBRARY_PATH can also be used to direct the search
  1594.      differently for different flavours of binary.  LD_LIBRARY_PATH
  1595.      shouldn't be necessary in normal operation; add the directories to
  1596.      /etc/ld.so.conf/ and rerun ldconfig instead.
  1597.  
  1598.   o  LD_NOWARN applies to a.out only.  When set (e.g. with
  1599.      LD_NOWARN=true; export LD_NOWARN) it stops the loader from issuing
  1600.      non-fatal warnings (such as minor version incompatibility
  1601.      messages).
  1602.  
  1603.   o  LD_WARN applies to ELF only.  When set, it turns the usually fatal
  1604.      ``Can't find library'' messages into warnings.  It's not much use
  1605.      in normal operation, but important for ldd.
  1606.  
  1607.   o  LD_TRACE_LOADED_OBJECTS applies to ELF only, and causes programs to
  1608.      think they're being run under ldd:
  1609.  
  1610.  
  1611.  
  1612.        $ LD_TRACE_LOADED_OBJECTS=true /usr/bin/lynx
  1613.                libncurses.so.1 => /usr/lib/libncurses.so.1.9.6
  1614.                libc.so.5 => /lib/libc.so.5.2.18
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.   7.4.
  1622.  
  1623.   Writing programs with dynamic loading
  1624.  
  1625.   This is very close to the way that Solaris 2.x dynamic loading support
  1626.   works, if you're familiar with that.  It is covered extensively in H J
  1627.   Lu's ELF programming document, and the dlopen(3) manual page, which
  1628.   can be found in the ld.so package.  Here's a nice simple example
  1629.   though: link it with -ldl
  1630.  
  1631.  
  1632.  
  1633.        #include <dlfcn.h>
  1634.        #include <stdio.h>
  1635.  
  1636.        main()
  1637.        {
  1638.          void *libc;
  1639.          void (*printf_call)();
  1640.  
  1641.          if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
  1642.          {
  1643.            printf_call=dlsym(libc,"printf");
  1644.            (*printf_call)("hello, world\n");
  1645.          }
  1646.  
  1647.        }
  1648.  
  1649.  
  1650.  
  1651.   8.  Contacting the developers
  1652.  
  1653.   8.1.  Bug reports
  1654.  
  1655.   Start by narrowing the problem down.  Is it specific to Linux, or does
  1656.   it happen with gcc on other systems?  Is it specific to the kernel
  1657.   version?  Library version?  Does it go away if you link static?  Can
  1658.   you trim the program down to something short that demonstrates the
  1659.   bug?
  1660.  
  1661.   Having done that, you'll know what program(s) the bug is in.  For GCC,
  1662.   the bug reporting procedure is explained in the info file.  For ld.so
  1663.   or the C or maths libraries, send mail to linux-gcc@vger.rutgers.edu.
  1664.   If possible, include a short and self-contained program that exhibits
  1665.   the bug, and a description both of what you want it to do, and what it
  1666.   actually does.
  1667.  
  1668.  
  1669.   8.2.  Helping with development
  1670.  
  1671.   If you want to help with the development effort for GCC or the C
  1672.   library, the first thing to do is join the linux-gcc@vger.rutgers.edu
  1673.   mailing list.  If you just want to see what the discussion is about,
  1674.   there are list archives at  <http://homer.ncm.com/linux-gcc/>.  The
  1675.   second and subsequent things depend on what you want to do!
  1676.  
  1677.  
  1678.  
  1679.  
  1680.   9.  The Remains
  1681.  
  1682.   9.1.  The Credits
  1683.  
  1684.  
  1685.  
  1686.        Only presidents, editors, and people with tapeworms have the
  1687.        right to use the editorial ``we''.
  1688.  
  1689.  
  1690.   (Mark Twain)
  1691.  
  1692.  
  1693.   This HOWTO is based very closely on Mitchum DSouza's GCC-FAQ; most of
  1694.   the information (not to mention a reasonable amount of the text) in it
  1695.   comes directly from that document.  Instances of the first person
  1696.   pronoun in this HOWTO could refer to either of us; generally the ones
  1697.   that say ``I have not tested this; don't blame me if it toasts your
  1698.   hard disk/system/spouse'' apply to both of us.
  1699.  
  1700.   Contributors to this document have included (in ASCII ordering by
  1701.   first name) Andrew Tefft, Axel Boldt, Bill Metzenthen, Bruce Evans,
  1702.   Bruno Haible, Daniel Barlow, Daniel Quinlan, David Engel, Dirk
  1703.   Hohndel, Eric Youngdale, Fergus Henderson, H.J. Lu, Jens Schweikhardt,
  1704.   Kai Petzke, Michael Meissner, Mitchum DSouza, Olaf Flebbe, Paul
  1705.   Gortmaker, Rik Faith, Steven S. Dick, Tuomas J Lukka, and of course
  1706.   Linus Torvalds, without whom the whole exercise would have been
  1707.   pointless, let alone impossible :-)
  1708.  
  1709.   Please do not feel offended if your name has not appeared here and you
  1710.   have contributed to this document (either as HOWTO or as FAQ).  Email
  1711.   me and I will rectify it.
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.   9.2.  Translations
  1718.  
  1719.   At this time, there are no known translations of this work.  If you
  1720.   wish to produce one, please go right ahead, but do tell me about it!
  1721.   The chances are (sadly) several hundred to one against that I speak
  1722.   the language you wish to translate to, but that aside I am happy to
  1723.   help in whatever way I can.
  1724.  
  1725.  
  1726.   9.3.  is welcomed.  Mail me atdan@detached.demon.co.uk.  My PGP public
  1727.   key (ID 5F263625) is available from myweb pages
  1728.   <http://ftp.linux.org.uk/~barlow/>, if you feel the need to be secre-
  1729.   tive about things.  Feedback
  1730.  
  1731.   9.4.  Legalese
  1732.  
  1733.   All trademarks used in this document are acknowledged as being owned
  1734.   by their respective owners.
  1735.  
  1736.   This document is copyright (C) 1996 Daniel Barlow
  1737.   <dan@detached.demon.co.uk> It may be reproduced and distributed in
  1738.   whole or in part, in any medium physical or electronic, as long as
  1739.   this copyright notice is retained on all copies. Commercial
  1740.   redistribution is allowed and encouraged; however, the author would
  1741.   like to be notified of any such distributions.
  1742.  
  1743.   All translations, derivative works, or aggregate works incorporating
  1744.   any Linux HOWTO documents must be covered under this copyright notice.
  1745.   That is, you may not produce a derivative work from a HOWTO and impose
  1746.   additional restrictions on its distribution. Exceptions to these rules
  1747.   may be granted under certain conditions; please contact the Linux
  1748.   HOWTO coordinator at the address given below.
  1749.  
  1750.   In short, we wish to promote dissemination of this information through
  1751.   as many channels as possible. However, we do wish to retain copyright
  1752.   on the HOWTO documents, and would like to be notified of any plans to
  1753.   redistribute the HOWTOs.
  1754.  
  1755.   If you have questions, please contact Tim Bynum, the Linux HOWTO
  1756.   coordinator, at linux-howto@sunsite.unc.edu via email.
  1757.  
  1758.  
  1759.   10.  Index
  1760.  
  1761.   Entries starting with a non-alphabetical character are listed in ASCII
  1762.   order.
  1763.  
  1764.  
  1765.   o  -fwritable-strings ``39'' ``56''
  1766.  
  1767.   o  /lib/cpp ``16''
  1768.  
  1769.   o  a.out ``1''
  1770.  
  1771.   o  ar ``10''
  1772.  
  1773.   o  as ``8''
  1774.  
  1775.   o  <asm/*.h> ``19''
  1776.  
  1777.   o  atoi() ``40''
  1778.  
  1779.   o  atol() ``41''
  1780.  
  1781.   o  binaries too big ``63'' ``65'' ``77''
  1782.  
  1783.   o  chewing gum ``3''
  1784.  
  1785.   o  cos() ``68''
  1786.  
  1787.   o  debugging ``59''
  1788.  
  1789.   o  dlopen() ``82''
  1790.  
  1791.   o  dlsym() ``83''
  1792.  
  1793.   o  documentation ``4''
  1794.  
  1795.   o  EINTR ``52''
  1796.  
  1797.   o  elf ``0'' ``71''
  1798.  
  1799.   o  execl() ``57''
  1800.  
  1801.   o  fcntl ``47''
  1802.  
  1803.   o  FD_CLR ``44''
  1804.  
  1805.   o  FD_ISSET ``45''
  1806.  
  1807.   o  FD_SET ``43''
  1808.  
  1809.   o  FD_ZERO ``46''
  1810.  
  1811.   o  file ``2''
  1812.  
  1813.   o  <float.h> ``20''
  1814.  
  1815.   o  gcc ``6''
  1816.  
  1817.   o  gcc -fomit-frame-pointer ``61''
  1818.  
  1819.   o  gcc -g ``60''
  1820.  
  1821.   o  gcc -v ``14''
  1822.  
  1823.   o  gcc, bugs ``15'' ``28'' ``29'' ``84''
  1824.  
  1825.   o  gcc, flags ``13'' ``25'' ``26''
  1826.  
  1827.   o  gdb ``64''
  1828.  
  1829.   o  header files ``17''
  1830.  
  1831.   o  interrupted system calls ``51''
  1832.  
  1833.   o  ld ``9''
  1834.  
  1835.   o  LD_* environment variables ``80''
  1836.  
  1837.   o  ldd ``81''
  1838.  
  1839.   o  libc ``7''
  1840.  
  1841.   o  libg.a ``62''
  1842.  
  1843.   o  libgcc ``79''
  1844.  
  1845.   o  <limits.h> ``21''
  1846.  
  1847.   o  lint ``58''
  1848.  
  1849.   o  <linux/*.h> ``18''
  1850.  
  1851.   o  manual pages ``5''
  1852.  
  1853.   o  <math.h> ``70''
  1854.  
  1855.   o  maths ``69''
  1856.  
  1857.   o  mktemp() ``55''
  1858.  
  1859.   o  optimisation ``27''
  1860.  
  1861.   o  QMAGIC ``76''
  1862.  
  1863.   o  segmentation fault ``30'' ``54''
  1864.  
  1865.   o  segmentation fault, in GCC ``33''
  1866.  
  1867.   o  select() ``50''
  1868.  
  1869.   o  SIGBUS ``34''
  1870.  
  1871.   o  SIGEMT ``35''
  1872.  
  1873.   o  SIGIOT ``36''
  1874.  
  1875.   o  SIGSEGV ``31'' ``53''
  1876.  
  1877.   o  SIGSEGV, in gcc ``32''
  1878.  
  1879.   o  SIGSYS ``38''
  1880.  
  1881.   o  SIGTRAP ``37''
  1882.  
  1883.   o  sin() ``67''
  1884.  
  1885.   o  soname ``73''
  1886.  
  1887.   o  sprintf() ``42''
  1888.  
  1889.   o  statically linked binaries, unexpected ``66'' ``78''
  1890.  
  1891.   o  <stdarg.h> ``23''
  1892.  
  1893.   o  <stddef.h> ``24''
  1894.  
  1895.   o  strings ``11''
  1896.  
  1897.   o  <sys/time.h> ``48''
  1898.  
  1899.   o  <unistd.h> ``49''
  1900.  
  1901.   o  <varargs.h> ``22''
  1902.  
  1903.   o  version numbers ``12'' ``74''
  1904.  
  1905.   o  weird things ``72''
  1906.  
  1907.   o  ZMAGIC ``75''
  1908.  
  1909.  
  1910.  
  1911.  
  1912.  
  1913.  
  1914.  
  1915.