Tech Insider					     Technology and Trends


		   Linux Activists Mailing List Archives

From: mitch@spuddy.uucp (Mitchum Dsouza)
Subject: GCC FAQ. Read this before posting.
Date: Mon, 24 May 1993 16:38:39 GMT

Hi all,

This is I hope the definitive FAQ for most GCC queries I have seen on the net.

Please read this before you post. It should hopefully reduce noise on this
channel.


Mitch


===========================Linux GCC FAQ==========================

1) How do I tell what version of GCC I am using ?
2) Where is the latest distribution of GCC, as, ld, ar,  etc.. ?
3) Where can I find the newest shared libraries libc.so and libm.so ?
4) What other shared libraries are available for Linux ?
5) How do I build a shared DLL library for Linux ?
6) Why do I get the message "PLT__oct__FUii" when I execute a certain binary ?
7) How do I build a cross compiler on platform XXX to produce code for Linux ?
8) What symbols are automatically defined by Linux's GCC ?
9) How do I get over BSD'isms (especially signals, sigvec etc..) when compiling code ?
10) Where are SIGBUS, SIGEMT, SIGIOT, SIGTRAP, SIGSYS  etc ?
11) What is libhard and libsoft ?
12) What does the message "can't load library: /lib/libxxx.so, Incompatible version" mean ?
13) Why are my binaries so huge and how do I reduce them ?
14) What does the -N flag do, and when should I use it ?
15) How do I get debugging information into a program ?
16) What debuggers are available for Linux ?
17) How do I debug a daemon program ?
18) What is profiling and how do I profile a program ?
19) Is there a way to tell if a binary is linked  statically or to a shared library ?
20) Does Linux have support for LD_LIBRARY_PATH ?
21) My program wants /lib/cpp ! Where can I get it from ?
22) Where is <varargs.h> ?
23) My program wants to include <linux/foo.h> but cannot find it, where is it ?
24) Do we have the function foo() in our libraries ?
25) How do I port program XXX to Linux ?
26) I think I have found a bug in gcc/library foo, what do I do now ?
27) Why are shared libraries so large in comparison to their static counterparts ?
28) What are .sa file I see in /usr/lib ?
29) Where can I get Objective C for Linux ?
30) What does the message "Internal compiler error: cc1 got fatal signal 11" mean ?
31) What is a libc.so.lite ?
32) Does Linux libraries have SHADOW Password support, and how do I switch it on/off ??
33) Can't find math.h routines ! My program compiles but cannot find log(), sin(), etc.., HELP !!
34) Is there a manual for GCC? If so, where do I get it, and how do I print it out ?
35) I get the message "Undefined symbol _bsd_ioctl". Where is this anyhow ??

================================================================

1) How do I tell what version of GCC I am using ?

Ans:    Execute the command
                gcc -v
        to find out what version you are using. At the time of writing the
        above command produces on my machine
                Reading specs from /usr/lib/gcc-lib/i386-linux/2.4.0/specs
                gcc version 2.4.0
        You would be well advised to upgrade to a version similar to this or
        above.

        P.S. If you get the output
                Reading specs from /usr/lib/gcc-lib/i486-linux/2.4.0/specs
                gcc version 2.4.0
        you are running a gcc compiled for a 486.

================================================================

2) Where is the latest distribution of GCC, as, ld, ar,  etc.. ?

Ans:    The Official place for GCC distributions is tsx-11.mit.edu in
        /pub/linux/packages/GCC. All others sites mirror this.
        The latest versions of all GCC stuff will be found here.

        At the time of writing the latest GCC is version 2.4 from
                tsx-11.mit.edu:/pub/Linux/GCC/a-gcc-2.4.0.tar.z

================================================================

3) Where can I find the newest shared libraries libc.so and libm.so ?

Ans:    See (2) above. You need the file image*.tar.z. For 486 images look
        under /pub/linux/packages/GCC/486.

================================================================

4) What other shared libraries are available for Linux ?

Ans:    Ok here is a list I have been compiling. Any additions/changes
        graciously received.

        The locations given below were where they were last seen (or
        reportedly seen). They may have been moved by archive maintainers.

        P.S. The descriptions of the libraries may not be obvious. I will
        add descriptions in a later table (i.e. when all are filled). Please
        send descriptions of the libraries (except the obvious) if you know
        what they are.

Here are the locations of currently registered DLL libraries for Linux.
======================================================================


libc.so         sunsite.unc.edu:/pub/Linux/GCC/image-4.4.tar.z
libm.so                 included in above tar.z file.

libX11.so       tsx-11.mit.edu:pub/linux/packages/X11/XFree86-1.2/x1.2.base.tpz
libXt.so                included in above tpz file.
libXaw.so               included in above tpz file.

librl.so        sunsite.unc.edu:/pub/Linux/libs/librl-1.1.tar.z
libgr.so        sunsite.unc.edu:/pub/Linux/libs/libgr-1.2.tar.z
libf2c.so       sunsite.unc.edu:/pub/Linux/development/fortran/libf2c-0.7.tar.z
libF77.so               use libf2c.so instead.
libI77.so               use libf2c.so instead.


libXpm.so       sunsite.unc.edu:/pub/Linux/libs/libXpm32g.tar.z
libnet.so       redundant (reintegrated into libc.so address space
librpc.so                               to be used for nis/yp and rpcsvc)

libolgx.so      sunsite.unc.edu:/pub/Linux/X11/devel/xview3l4.tar.z
libxview.so             included in above tar.z file.
libsspkg.so             included in above tar.z file.
libUIC.so               included in above tar.z file.

libPEX.so

libtcl.so       sunsite.unc.edu:/pub/Linux/development/tcl/tclDist.tar.z
libtk.so                included in above tar.z file.

libWc.so
libXp.so

libIV.so
libUnidraw.so

libXm.so(motif) Not free. See note below.

libsrgp.so      sunsite.unc.edu:/pub/Linux/X11/devel/suit.tpz
libsuit.so              included in above tpz file.

============
Note:-

Drop in DLL libraries for Xaw to get a 3d effect (libXaw3d-0.6) and a Mac(TM)
like scroll bar on Xaw clients are available respectively at

        sunsite.unc.edu:/pub/Linux/libs/libXaw3d-3.0-B.tar.z
and
        sunsite.unc.edu:/pub/Linux/libs/libXaw.Scrollbar.taz

For motif libs you have to pay bucks !! Read an extract that follows...
======
Metro Link, Inc. is pleased to announce the availability of OSF/Motif 1.2.2
for Linux at the introductory price of $199 for a complete runtime and
development system.

[...]

    2) Shared motif library (libXm.so.1.2.2)

[...]

This introductory offer is valid until June 10. The price will then return
to our regular Motif pricing which is $199 for runtime and $299 for
development
(which includes runtime).

You can order OSF/Motif 1.2.2 for Linux by calling Metro Link,Inc. at
(305) 970-7353 (voice) or (305) 970-7351 (fax) or by mailing us at
sales@metrolink.com.

================================================================

5) How do I build a shared DLL library for Linux ?

Ans:    You need to get the file
                /pub/linux/packages/GCC/src/tools-2.6.tar.z
        from tsx-11.mit.edu, and install it. Read the README.tr in the doc
        subdirectory thoroughly. If you find the README.tr more up to date 
        than the README.ps, you will have to recreate it if you want a
        pretty Postscript version, but you *must* have groff installed. A
        `make README.ps' in the doc subdirectory should suffice.

        ** Note: the version numbers may have changed.

================================================================

6) Why do I get the message "PLT__oct__FUii" when I execute a certain binary ?

Ans:    More likely than not you have a old version of the libraries, libc.so
        and/or you compiled a program using a incorrect version of `ld'.
        Solution is to get the new version of binutils package from
                tsx-11.mit.edu in /pub/linux/packages/GCC/binutils.tar.z

================================================================

7) How do I build a cross compiler on platform XXX to produce code for Linux ?

Ans:    Assuming you have obtained the source code to gcc, usually you can
        just follow the instructions given in the INSTALL file for GCC.
        A `configure --target==i386-linux --host=XXX' on platform XXX
        followed by a `make' should do the trick.
        Note that you will need the linux includes, the kernel includes,
        and also to build cross assembler, and cross linker from the sources
        in /pub/linux/packages/GCC/src at tsx-11.mit.edu

================================================================

8) What symbols are automatically defined by Linux's GCC ?

Ans:    Symbols defined are `linux', `__unix__', `__i386__', `__linux__',
        `__unix', `__i386', `__linux'.
        You can get a correct list by using the flag -v to gcc whilst
        compilation.

        P.s. One should note that even though the compiler automatically
        defines "linux" in a program, this is *not* POSIX compliant. Instead
        __linux__ should be used in programs that need operating-system
        specific compilation, since __linux__ *is* POSIX compliant.

        This means you can wrap your linux specific code around (for example)

        #ifdef __linux__
        ...[linux specific code here]...
        #endif /* ifdef linux */

        without adding anything extra to the Makefile defines etc..

        You can also add your own defines to the file
                /usr/lib/gcc-lib/i386-linux/2.4.0/specs

================================================================

9) How do I get over BSD'isms (especially signals, sigvec etc..) when compiling code ?

Ans:    You can compile your program with -I/usr/include/bsd and link it
        with -lbsd - i.e. Add -I/usr/include/bsd to CFLAGS and -lbsd to
        the LDFLAGS line in your Makefile. Also add -D__USE_BSD_SIGNAL to
        the CFLAGS if you want BSD type signal behavior.

================================================================

10) Where are SIGBUS, SIGEMT, SIGIOT, SIGTRAP, SIGSYS  etc ?

Ans:    Linux is 100% POSIX compliant and these signals are not POSIX
        signals. As an easy way out you could redefine them to SIGUNUSED.
        See the definitions in /usr/include/bsd/signal.h 

        However you should note that the lack of these signals *is* compliant
        with POSIX. Instead of #define'ing to them to SIGUNUSED, new programs
        should instead say:

        #ifdef SIGSYS
        ....[non-posix sigsys code here]....
        #endif

        for code that requires the use of SIGSYS (similarly for SIGBUS).

        Here is a snippet from ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990),
        paragraph B.3.3.1.1: 

        "The signals SIGBUS, SIGEMT, SIGIOT, SIGTRAP, and SIGSYS were
        omitted from POSIX.1 because their behavior is implementation
        dependent and could not be adequately categorized.  Conforming
        implementations may deliver these signals, but must document the
        circumstances under which they are delivered and note any
        restrictions concerning their delivery."

================================================================

11) What is libhard and libsoft ?

Ans:    These are the libraries for the math emulation routines - the hard
        if you had hardware to do math (i.e. a 387), or soft if emulation of
        math routines was done in software.
        You do not need these libraries if you are using a current version
        of Linux, as math emulation is now done at kernel level - (i.e if
        you enabled it when you did a `make config' at kernel build time).
        Otherwise your 387 will do the work. You may safely remove them if
        your link /lib/libm.so.4 points to a libm.so.4.x.y

================================================================

12) What does the message "can't load library: /lib/libxxx.so, Incompatible version" mean ?

Ans:    As shared libraries evolve it is necessary to have some sort of
        version numbering such that a program may be able to determine
        whether its execution will cause it to crash. This will happen for
        example if a function call has changed radically or doesn't exist.

        Say we have a library - libc.so.4.3.3
                                   T    T T T
                                  /    /  |  \
                                 /    /   |   \
                                /    /    |    \
                     Library name   /     |     \
                                   /      |      \
                          Version no.     |      Minor version no.
                                          |
                                  Major version no.

        In general if the Version no. changes you will definetly NOT be able
        to execute a program that was compiled with a different library. i.e
        it is no use attempting to create a link from libc.so.4.3.3 to
        libc.so.2 if your program requires libc.so.2.

        If the Major version no. changes, then you will only be allowed to
        execute a program if the Major version number of the current library
        you are running is *greater* (or equal of course) than that the
        program was compiled with. This means if your program is compiled
        when you had libc.so.4.3.3 you will be still able to execute it if
        you get a more recent version of the DLL library, say libc.so.4.3.4,
        but then do not expect to be able to execute the program if you
        decide to go back to say libc.so.4.2

        The Minor version no. is as name suggests, an indication that a very
        minor change has undergone in the shared DLL library, usually a typo
        or small bug fix in the library code. The minor version no. may be
        left out totally from the naming convention.

        So getting back to the question, it usually means that you are
        trying to run a binary and you don't have the correct library(ies)
        installed on your system. To rectify the situation get the latest
        libs - See questions (3), (19).

================================================================

13) Why are my binaries so huge and how do I reduce them ?

Ans:    If you want smaller binaries there are a number of things you can do.
        * Optimize the code - Use the -O6 flag when compiling,
        * Strip the resultant binary - Use the -s flag at the ld stage.
        * Make the binary impure - Use the -N flag at the ld stage.

        A combination of any/all of these may be used.

        The linker `ld' will choose by default to link your program to the
        shared libraries. However if it doesn't find the relevant stubs
        (i.e. the .sa files) *OR* the these files are unreadable by the user
        then it will attempt to link static (i.e. to the .a files). This
        may be a reason why your binaries are so huge. The search path it
        looks for these .sa and .a libraries are /usr/lib, then /lib and then
        /. This means you may intersperse the stubs and DLL shared libs
        anywhere in these directories. More flexibility will soon be
        available - See also (20)

        Also many of the FSF authors believe that we want to debug their
        programs, and leave the -g option in their Makefiles. The result is
        that large amounts of debugging symbols are left in and the program
        is linked statically. Check the Makefile carefully to make sure -g
        has been removed from either the CFLAGS and/or the LDFLAGS if you are
        compiling software and you are satisfied with it's operation.

================================================================

14) What does the -N flag do, and when should I use it ?

Ans:    A demand paged binary can be swapped.  If you use the -N option you
        get an impure executable file which does not have its various
        segments padded out to page boundaries; as a consequence it cannot
        be swapped or shared.

        This is usually irrelevant for very small programs, which is why they
        are often compiled with -N.  Large programs (eg. gcc or emacs), or
        programs which are likely to have multiple instances (like the shell
        or xterm), should be compiled without -N so that their code pages can
        be shared.  If you start to run out of memory, the kernel can start
        to delete unused code pages from demand pages executables - they can
        always be reloaded later.  This is impossible for impure executables.

        So, if your program is likely to use significant amounts of memory,
        then don't use -N or the kernel's memory management will be
        obstructed.

        Clearly `one-off' programs can all be compiled using this flag -
        i.e. anything which doesn't stay for long periods of time in memory,
        say for example hostname, fsck, mkfs, w, etc.. Do *not* use the -N
        flag on daemons, which by nature are meant to be resident in memory.

================================================================

15) How do I get debugging information into a program ?

Ans:    You need to compile your program (i.e. all objects) and also link it
        with the -g flag on - in other words compile *everything* with -g.
        If you end up at the linker stage with a message like
                Can't find libg.a
        then you need to get from tsx-11.mit.edu the file
                /pub/linux/packages/GCC/extra*.tar.z
        However enough debugging information may be gleaned by simply doing
                % cd /usr/lib; ln -s libc.a libg.a
        on your linux machine.
        Make sure *NOT* to strip the binary if you want to perform debugging.

================================================================

16) What debuggers are available for Linux ?

Ans:    Well of course, the best debugger available ever is `gdb'. Look for
        it at your favorite site. Eg:
                sunsite.unc.edu:/pub/Linux/development/gdb-4.8.z
        An X debugger based on this, (i.e. you need gdb installed first), is
        also available there (xxgdb).

================================================================

17) How do I debug a daemon program ?

Ans:    Simply put, you have to get the daemon program not to fork before
        you can debug it. 

        However using the debugger `gdb' you can attach to the daemon even
        *after* it has forked. You do this by telling gdb the process id
        that you want to debug. (I forget the exact details; I usually use
        gdb's internal help when I want those esoteric extras.)

        Also if you are not in possession of the source, and the binary is
        stripped you can obtain the program `strace', attach it to the
        daemon process id and examine the output produced. This can be useful
        if you know what you are looking for.

================================================================

18) What is profiling and how do I profile a program ?

Ans:    Profiling is a way to examine where and which functions time is being
        spent on, the number of calls made to a certain function and total
        execution times. It is a good way to optimize code and look at where
        time is being unnecessarily wasted.
        To enable profiling all objects and linking must be compiled with
        the -p flag. See question (15) on where to get the libraries
        necessary for profiling.

        To actually get a graph profile you need also the program `gprof'.
        You will find it included in the binutils package.
        Again, find it at your favorite Linux archive site. Eg:
                tsx-11.mit.edu:/pub/linux/packages/GCC/binutils.tar.z


================================================================

19) Is there a way to tell if a binary is linked  statically or to a shared library ?

Ans:    Yes.
        Use the utility `ldd'. This gives you information on what libraries
        are required. If no output is generated when you run `ldd' on a
        program then it indicates the program was linked statically.

        Eg (1): the command (on my linux system)
                % ldd /bin/init
        gives no output meaning init was linked statically. And a good thing
        too it was linked statically :-)

        Eg (2): the command (on my linux system)
                % ldd /usr/bin/gs
        i.e. the ghostscript interpreter gives the following output.
                libm.so.4       => /lib/libm.so.4.4 (4.0)
                libX11.so.3     => /lib/libX11.so.3.0 (DLL Jump 3.0pl0)
                libc.so.4       => /lib/libc.so.4.4 (DLL Jump 4.3)
        This tells me that the program `gs' was dynamically linked and
        requires three shared libraries. The numbers in brackets tell me
        that only one library, (libX11), matches the current version of the
        library I have when the program was compiled. When `gs' was compiled
        the math library, (libm), I had was version 4.0 and not a DLL
        library, but it will happily run with my 4.4 DLL shared version.
        Similarly my current c library, (libc), is a version greater that
        when I compiled `gs'.

        Note: your version of `ldd' may have a somewhat different output.

================================================================

20) Does Linux have support for LD_LIBRARY_PATH ?

Ans:    Yes and No.
        Unlike some commercial systems, (eg: Sun-OS), whose dynamic linker is
        in fact a dynamic library, Linux's dynamic linker is a static object
        in the form of __load.o which appears in the libc.sa stub and
        automatically gets linked into every binary you build. This means
        that changes to __load.o take a very long time to propagate and
        appear in every single binary.

        So to answer the question is, Yes, it is supported if anything is
        compiled using library versions greater that 4.3.4 (libc.so.4.3.4)
        and above, but the upshot is that you will not notice it unless you
        recompile *all* your binaries.

        A change to this behavior may be imminent. Watch this space.....

================================================================

21) My program wants /lib/cpp ! Where can I get it from ?

Ans:    cpp appears in /usr/lib/gcc-lib/i386-linux/2.4.0
        (the gcc version numbers may have changed when you read this)
        You need to do the following
                % cd /lib; ln -sf /usr/lib/gcc-lib/i386-linux/2.4.0/cpp
        ** Change the 2.4.0 to whatever version of GCC your are using.
        ** Change the i386 to i486 if using the 486 compiler

        An alternative, and possibly better solution is this:

                % cat > /lib/cpp
                #!/bin/sh
                cc -E "$@"
                Ctrl-D[EOF]

        This way /lib/cpp won't stop working when you switch to a newer gcc
        version and delete the old one.

================================================================

22) Where is <varargs.h> ?

Ans:    varargs.h appears with other system dependent files in
                /usr/lib/gcc-lib/i386-linux/2.4.0/include
        <varargs.h> is K&R stuff. By default, gcc is ANSI. <stdarg.h> should
        be used instead.

        ** Change the 2.4.0 to whatever version of GCC your are using.

================================================================

23) My program wants to include <linux/foo.h> but cannot find it, where is it ?

Ans:    As some of the includes are kernel version dependent, they are thus
        kept along with the kernel releases. You need to get the latest
        kernel sources, unpack them and then make appropriate links.

        If say you unpacked the kernel source in /usr/src such that you have
        a /usr/src/linux directory, then you should do the following:
                % cd /usr/include
                % ln -sf /usr/src/linux/include/linux
                % ln -sf /usr/src/linux/include/asm

================================================================

24) Do we have the function foo() in our libraries ?

Ans:    An easy way to check out whether a function is supported in a
        certain library is to do the following, say you are unsure
        whether flock() is supported ...
                % nm /usr/lib/libc.a | grep flock

        If you get something like
                00000000 T flock
        flock() is defined in libc.a/libc.sa.

        If you only get lines like
                00000000 U flock
        it only indicates a reference to flock(). The `U' means that flock is
        defined elsewhere and you need to include the library where it is
        defined such that the reference can be resolved.

================================================================

25) How do I port program XXX to Linux ?

Ans:    Gone are the days when one had to `port' a program to Linux.
        These days if something hasn't been ported to Linux then it is not
        worth having :-)

        Seriously thought, in general only minor changes are needed to the
        sources to get over Linux's 100% POSIX compliance. It is also worthwhile
        passing back any changes to authors of the code such that in future
        only `make' need be called to provide a working executable.

        One of the most common problems are that some common functions are
        defined as macros in Linux's header files and the preprocessor will
        refuse to parse similar prototype definitions in the code. Common
        ones are  atoi() and atol().

================================================================

26) I think I have found a bug in gcc/library foo, what do I do now ?

Ans:    Have you really ??
        Well first try and narrow the code down to a few lines and see if
        the program still fails/doesn't work as expected.
        Does the same behavior occur both with a static and shared version ??
        (i.e. is it a problem with the DLL libs, or the static libs)

        Have you access to another platform running gcc ? In other words is
        the problem a GCC one as opposed to a Linux/GCC one ? If so you may
        want to post to USENET newsgroups gnu.gcc.bug or gnu.gcc.help

        Is the problem in the math emulator ? If so you could email
        Bill Metzenthen (apm233m@vaxc.cc.monash.edu.au) the writer of the
        emulator code.

        Finally you could try emailing linux-bugs@sunsite.unc.edu, myself
        (mitchum.dsouza@mrc-apu.cam.ac.uk) or even HLU.

================================================================

27) Why are shared libraries so large in comparison to their static counterparts ?

Ans:    Shared libraries reserve space for future expansion in the form of
        `holes' which can be made to take no disk space. A simple cp call
        or using the program `makehole' will achieve this.
        You can also strip your libraries after you build them

================================================================

28) What are .sa file I see in /usr/lib ?

Ans:    The .sa files are the stubs to the shared libraries and contain all
        global variables from a certain library, and pointers to functions
        required for run time linking. See also question (13).


================================================================

29) Where can I get Objective C for Linux ?

Ans:    Objective C will be in the next release of gcc for Linux (i.e
        gcc-2.4.0 and above). This is currently untested at the moment.

================================================================

30) What does the message "Internal compiler error: cc1 got fatal signal 11" mean ?

Ans:    Gcc is probably the biggest memory hog you likely to run on your
        machine and it will surely eat up a lot of your RAM. Usually a fatal
        signal 11 will mean some sort of parity errors in your RAM or other
        hardware faults. I had this once when a cc1 got corrupted due to a
        race condition and bad blocks on my hard disk.

================================================================

31) What is a libc.so.lite ?

Ans:    A libc.so.lite is a light-weight version of the libc library built
        such that it will fit on a floppy and suffice for all of the most
        menial of UNIX tasks. It does *not* include curses, dbm, termcap etc
        code. If your /lib/libc.so.4 is linked to a lite lib, you are advised
        to replace it with a full version. See question (3) on where it is
        available from.

================================================================

32) Does Linux libraries have SHADOW Password support, and how do I switch it on/off??

Ans:    Yes.
        You need to compile programs with the defines SHADOW_PWD in place,
        and link it with the shadow library - available separately in:
                sunsite.unc.edu:/pub/Linux/distributions/SLS/a4/shadow.tgz
        This means adding -DSHADOW_PWD to the CFLAGS line in the Makefile, and
        -lshadow in the LDFLAGS line.

        This means that there is NO WAY of switching shadow password'ing
        on/off without having to compile *all* necessary binaries which use
        the getpwent(), setpwent() etc routines.

================================================================

33) Can't find math.h routines ! My program compiles but cannot find log(), sin(), etc.., HELP !!

Ans:    When you compile a program using certain functions, you *must* also
        link the program to the appropriate library. This means for math
        functions you have to include libm.a at the linker stage, i.e. add
        -lm to the LDFLAGS, for curses functions add -lcurses, for dbm
        functions add -ldbm etc...

================================================================

34) Is there a manual for GCC? If so, where do I get it, and how do I print it out ?

Ans:    There is a file on sunsite in the GCC directory
                sunsite.unc.edu:/pub/Linux/GCC/gcc-man.tar.z
        This file contains the man pages cccp.1, cpp.1, g++.1 and gcc.1. Also
        one can get the full manual from any local ftp site that carries GCC
        and other FSF goodies. You will require TeX to make the manual from
        the GCC source distribution.

================================================================

35) I get the message "Undefined symbol _bsd_ioctl". Where is this anyhow ??

Ans:    You forgot to include the bsd library /usr/lib/libbsd.a into your
        program at the linking stage.

        Solution: Add -lbsd to the Makefile LDFLAGS line. (or add it
        manually if it doesn't have a LDFLAGS line)

============================================================================

                       Acknowledgements: (in no order)

                                  H.J.Lu
                               Dirk Hohndel
                                David Engel
                              Eric Youngdale
                             Bill Metzenthen
                                Rik Faith
                              Steven S. Dick
                               Bruno Haible

                              and of course

                              Linus Torvalds

============================================================================

N.B. Please do not feel offended if your name has not appeared here and you
have contributed however significantly/insignificantly. It is entirely my
fault.

============================================================================

Please help in making this FAQ the definitive answer repository of Linux GCC
queries by e-mailing questions, (and answers if you have them), corrections
and additions to me

                    Mitchum DSouza <m.dsouza@uk.ac.cam.mrc-apu>

-- 

 * Meeeow ! Call Spuddy on (0203) 364436/362560 for FREE mail & Usenet access *

			      USENET Archives


The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 
research.


Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/