# Linux GCC FAQ 1st Feburary 1994

    0) Where can I get the latest version of this 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.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 ?
    36) If I upgrade versions, can I get rid of the old stuff from /usr/lib/gcc-lib/i[34]86-linux/<old-version> ?
    37) [HELP] where is libipc.a ? Needed for dosemu 0.49..
    38) XXX won't compile: _daemon undefined, help !!
    39) [HELP] ar and libraries. Linking fails although symbol appears in library.
    40) HELP! newbie gets warning message "libc.so.4: incompat. minor ver no."
    41) Where can I find `lint' to check my c programs before compilation ?
    42) My program needs sgtty.h where is it ?
    43) How do I stop or start core files being produced SIGSEGV's  ?
    44) What does the message "can't load dynamic linker `/lib/ld.so'" mean ?
    45) What is the difference between -O2 and -O6 optimizations ?
    46) How can I check an unknown binary to see if it is a trojan horse ?
    47) Where are the sources to the C library - how do I rebuild it ?
    48) Where are the definitions of FD_* stuff ?
    49) When linking with option -g I get undefined ___fpu_control and ___setfpucw ?
    50) Where can I get the tools to Internationalize my library/application ?
    51) The DLL tool `mkimage' fails with to find libgcc. Help!!!
    52) How do I get rid of "__NEEDS_SHRLIB_libc_4 multiply defined" messages ?
    53) What is this QMAGIC thing everyone is talking about ?
    54) How do I generate a QMAGIC executable/library ?
    55) Is it possible to turn the "warning using incompatable library version xxx" messages off ?

    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    0) Where can I get the latest version of this FAQ ?

    Ans:	The latest versions are posted to comp.os.linux.announce periodically,
    	and archived in at most popular Linux sites, e.g.

    		sunsite.unc.edu:/pub/Linux/docs/faqs

    		rtfm.mit.edu:pub/usenet/news.answers

    -------------------------------------------------------------------------------

    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.5.7/specs
    		gcc version 2.5.7
    	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.5.7/specs
    		gcc version 2.5.7
    	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 for Linux is
    	2.5.7 and available from
    		tsx-11.mit.edu:/pub/linux/packages/GCC/gcc-2.5.7-p1.tar.gz

    	However this does not mean that this is the latest available
    	version of GCC from the GNU foundation. This is just the latest
    	*distribution*.

    	The Linux GCC maintainer(s) have made it easy for you to compile the
    	latest version available yourself. The configure script with GCC
    	sources should set it all up for you.

    	You will also need the latest include (header) files if you wish to
    	compile stuff. At the time of writing the latest includes can be
    	obtained from
    		tsx-11.mit.edu:/pub/linux/packages/GCC/inc-4.5.8.tar.gz

    -------------------------------------------------------------------------------

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

    Ans:	See question (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. For a more obvious description of the libraries below,
    	their maintainers and their registered start/end address please
    	read the `doc/table_description' file in the tools-x.y.tar.z package.
    	See the following question (5) on where to obtain this from.

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

    libc.so		tsx-11.mit.edu:/pub/linux/packages/GCC/image-4.5.8.tar.gz
    libm.so			included in above tar.gz file.

    libX11.so	tsx-11.mit.edu:pub/linux/packages/X11/XFree86-2.0/xf86-lib-2.0.tar.gz
    libXt.so		included in above tar.gz file.
    libXaw.so		included in above tar.gz 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/devel/fortran/libf2c-0.9.tar.gz
    libF77.so		use libf2c.so shown above instead.
    libI77.so		use libf2c.so shown above instead.

    libXpm.so	sunsite.unc.edu:/pub/Linux/libs/libXpm32g.tar.z

    libnsl.so	ftp.lysator.liu.se:/pub/NYS/nys-0.xx.tar.gz

    libolgx.so	sunsite.unc.edu:/pub/Linux/libs/xview3L5.1.tar.gz
    libxview.so		included in above tar.gz file.
    libsspkg.so		included in above tar.gz file.
    libUIT.so		included in above tar.gz file.

    libPEX.so	tsx-11.mit.edu:pub/linux/packages/X11/XFree86-2,0/xf86-pex-2.0.tar.gz

    libtcl.so	sunsite.unc.edu:/pub/Linux/devel/tcl/*
    libtk.so		various related tcl/tk stuff included in above tar.gz files.

    libWc.so		Unknown
    libXp.so		Unknown

    libIV.so	nic.funet.fi:/pub/OS/Linux/images/Slackware/iv1/iv*.tgz
    libUnidraw.so		included in above .tgz files.

    libXm.so	The Motif library is *not* free. See note below.

    libsrgp.so	sunsite.unc.edu:/pub/Linux/X11/devel/suit.tpz
    libsuit.so		included in above tpz file.  (reported not shared)

    libOI.so	tsx-11.mit.edu:/pub/linux/packages/OI/oi40.tar
    libOIrg.so		included in above tar file.

    libld.so	tsx-11.mit.edu:/pub/linux/packages/GCC/ldso-1.4.tar.gz
      			(required for libc 4.4.4 and above.)

    libarma.so	ftp.atnf.csiro.au:/pub/karma
    libkarmaX11.so		see above site
    libkarmaXt.so		see above site
    libkarmagraphics.so	see above site
    libkarmawidgets.so	see above site
    libkarmaxview.so	see above site

    libwxwin.so	sunsite.unc.edu:/pub/Linux/X11/devel/wxWin_linux.tgz

    libandrew.so	sunsite.unc.edu:/pub/Linux/X11/andrew/andrew61.prog.tar.gz

    libUil.so		Commercial library.

    libBLT.so	sunsite.unc.edu:/pub/Linux/devel/tcl/blt1.0-bin.tar.z

    libvga.so	sunsite.unc.edu:/pub/Linux/libs/svgalib097.tgz

    libitcl.so	sunsite.unc.edu:/pub/Linux/devel/tcl/itcl1.3-bin.tar.z

    ------------
    Note 1:-

    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

    Note 2:-

    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 $199 for a complete runtime and development system.

    Requirements:
    	Linux 0.99pl4 or greater (currently 0.99pl12 O.K.)
    	XFree86 1.2 or greater (1.3 O.K.)
    	libc 4.3.3 or greater (libc 4.4 is O.K.)

    What is included:

    Runtime:
        1) Motif Window Manager (mwm)
        2) Shared motif library (libXm.so.1.2.2)
        3) Motif demos both from OSF and from the net

    Development:
        2) Static Mrm and Uil libraries
        3) UIL compiler
        4) Motif header files
        5) Manual pages for Motif function calls
        6) Imakefile support
        7) Source to OSF/Motif demos

    And your choice of any one of the X-window books published by O'Reilly &
    Associates, Inc.

    You can order OSF/Motif 1.2.2 for Linux by calling Metro Link,Inc. at
    sales@metrolink.com.

    ==============================================================================
      Metro Link Incorporated.  2213 W. McNab Rd. Pompano Beach,  Florida  33069
     X11.5 and OSF/Motif for QNX, SVR3, SVR4.[012], SCO, Linux, UnixWare, LynxOS,
                      AT&T, Venix, ISC, Solaris, Pyramid, SunOS
                WATCH your: Word Action Thought Character Heart
    ==============================================================================

    -------------------------------------------------------------------------------

    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.10.tar.gz
    	from tsx-11.mit.edu, and install it. Read the README.tr in the doc
    	subdirectory thoroughly - a lot of effort has been put into this to
    	make it readable and possible for everyone to be able to build a
    	shared DLL.

    	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'.
    	The solution is to get the new version of binutils package from
    		tsx-11.mit.edu in /pub/linux/packages/GCC/binutils-as.tar.gz

    -------------------------------------------------------------------------------

    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-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

    	Here is an example of building a cross compiler on a Sparc (Sun) to
    	produce code for a linux machine. This is the easy way, using linux
    	libraries compiled by HLU that you already are using on your linux
    	machine. For some of this I STRONGLY advise you to get GNU's make
    	(gmake) to use for some of the compilations (binutils and gas will
    	fail using the included Makefiles.linux with Sun's make)

    	7.1) Lets assume you already have a working gcc version 2.4.5 on the
    	     Sun in /usr/local/bin with all standard install paths - i.e the
    	     compilers are in /usr/local/lib/gcc-lib.

    	     First make the linux specific directories (you may need to make
    	     the intermediate directories too) up to

    		% mkdir -p /usr/local/lib/gcc-lib/i386-linux-linux/bin
    		% mkdir -p /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/include
    		% mkdir    /usr/local/lib/gcc-lib/i386-linux-linux/include

           7.2) Start by setting some environment variables so you don't have to
    	    type long pathnames. Set this in your .login or .cshrc also as you
    	    will need to use l-ar, l-ranlib for cross compiling DLL's etc..
    	    For the moment you can do the following

    	    In csh:
    	       % setenv LBINS /usr/local/lib/gcc-lib/i386-linux-linux/bin/
    	    In sh:
    	       % LBINS=/usr/local/lib/gcc-lib/i386-linux-linux/bin/
    	       % export LBINS

    	    Put *ALL* linux specific header file with all the contents of the
    	    subdirectories linux, asm, gnu, sys etc.. in ${LBINS}../include
    	    Make SURE of this. See questions (2) and (23) on where to get
    	    these from. You will have to do this each time a new kernel is
    	    released.

    	    On my linux machine sitting next to my sun I can say

    		% rcp -r linux_machine:/usr/include ${LBINS}../

    	    Otherwise you will need to get the includes and kernel sources, see
    	    questions (2), to achieve this. Also you will want the gnu specific
    	    files like limits.h, varargs.h, stdargs.h  etc... Again from my
    	    linux machine I can say

    		% rcp -r \
    		    linux_machine:/usr/lib/gcc-lib/i386-linux/2.4.5/include \
    			${LBINS}../2.4.5

    	   You may have to change the i386 or 2.4.5 depending on your machine
    	   and version of gcc.

    	7.3) Now you have to extract and compile the cross assembler and
    	     linker:

    	     Get the following files

    	     tsx-11.mit.edu:/pub/linux/packages/GCC/src/binutils-1.9l.3.tar.gz
    	     tsx-11.mit.edu:/pub/linux/packages/GCC/src/gas-1.38.1l.2.tar.gz

    	     and extract them somewhere.

    	7.3.1)  In the binutils dir binutils-1.9l.3:
    		Edit Makefile.linux and change the line that has the bindir
    		definition to have

    		        bindir=${LBINS}

    		and the appropriate block for your machine ("sun4" in this
    		case) line to

    			HOST_ROOT=${LBINS}..

    		For 0.99pl12 (and above probably) you will have to copy
    		a.out.h and page.h to a directory and include it in the
    		MISCFLAGS. So in the current binutils dir, do this

    			% mkdir linux
    			% cp ${LBINS}../include/linux/a.out.h linux
    			% cp ${LBINS}../include/linux/page.h linux

    		and then edit the Makefile.linux and add -I. to the
    		appropriate MISCFLAGS line.

    		Then do
    			% make -f Makefile.linux archpfx= install

    		To be able to do l-ar, l-ranlib for the linux ar, ranlib
    		utilities, do the following (I put the l-blah into my
    		private ${HOME}/bin directory)
    			% sh -c 'for i in ${LBINS}*; do \
    			          ln -s $i ${HOME}/bin/l-`basename $i`; done'

    	7.3.2)	*******FOR gas-1.38.1l.1*******

    		In the the assembler directory gas-1.38.1l.1:
    		Edit the makefile.linux file and change the appropriate lines
    		to read the following

    			LINUX_INCDIR=

    			HEADERS=-DA_OUT_H=\"${LBINS}../include/linux/a.out.h\"

    		Then type (lots of warnings will appear)

    			% make -f makefile.linux

    		Copy the cross assembler binary manually

    			% cp a386 ${LBINS}as

    		*******FOR gas-2.2 (and above)*******

    		In the the assembler directory do

    			% ./configure --host=sun4 --target=i386-linux-linux
    			% make CC=gcc CFLAGS=-O2 LDFLAGS=-s

    	7.3.3)	Finally make the two links

    			% ln -s ${LBINS}as ${LBINS}../2.4.5/as
    			% ln -s ${LBINS}ld ${LBINS}../2.4.5/ld

          7.4) Now in the GCC source directory you extracted on your Sun do the
    	   following.

    		% ./configure --host=sun4 --target=i386-linux-linux
    		% make	CC=/usr/local/bin/gcc CFLAGS="-O2 -s" \

    	   This may end with a error when building the library libgcc.a ignore
    	   it. All you want are the cross compiler binaries in this instance.

          7.5) After that finishes, copy the binaries to the proper places...

    		% cp cc1 cc1plus cpp cc1obj ${LBINS}../2.4.5

    	   Copy the front end to the compiler to the bin directory and make
    	   a easy link somewhere (maybe your ~/bin)

    		% cp xgcc ${LBINS}gcc
    		% ln -s ${LBINS}gcc ${HOME}/bin/gcc-linux

          7.6) Get all your libs from your linux machine

    		% rcp linux_machine:/usr/lib/lib\*a ${LBINS}../2.4.5
    		% rcp linux_machine:/usr/X386/lib\*a ${LBINS}../2.4.5
    		% rcp linux_machine:/usr/lib/crt0.o ${LBINS}../2.4.5

          7.7) Thats it. Try compiling something. Lots of well written packages
    	   will let you do the following (assuming you have the path to your
    	   ${HOME}/bin set)

    		% make CC="gcc-linux -O6 -s" RANLIB=l-ranlib AR="l-ar"

          7.8) If you want to cross compile shared DLL's then you must also get

    		tsx-11.mit.edu:/pub/linux/packages/GCC/src/tools-2.10.tar.gz

    	   Use the Makefile.cross in the tools subdirectory to compile a
    	   cross version. Change the definition at the top of the
    	   Makefile.cross to look like

    		CROSSBINDIR=${LBINS}
    		CROSSINCDIR=${LBINS}../include

    	   Finally change the BINDIR definition. I set it to ${LBINS}../dll/bin
    	   This will also create a ${LBINS}../dll/jump for you. Then a

    		% make -f Makefile.cross install

    	   should do the business.

    -------------------------------------------------------------------------------

    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/i486-linux/2.5.7/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). There is *no* need to add
    	-D__USE_BSD_SIGNAL any more if you want BSD type signal behavior,
    	as this is added automatically when you do the -I/usr/include/bsd

    -------------------------------------------------------------------------------

    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   /     |     \
                                       /      |      \
                        Major version no.     |      Patch level.
                                              |
                                      Minor version no.

    	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 matches that with which the program was linked with.
    	This means if your program is compiled when you had libc.so.4.3.3
    	you will not be able to execute it if you get a more recent version of
    	the DLL library, say libc.so.5.1.2. I.e it is no use attempting to
    	create a link from libc.so.5.1.2 to libc.so.4 if your program requires
    	libc.so.4.

    	The Minor version no. is as name suggests, an indication that a
    	minor change has undergone in the shared DLL library, maybe just a
    	new addition of a function, and shows that backward compatability
    	is still retained. If you attempt to use a library whose minor
    	version number is smaller than what the binary was originally
    	compiled with then a warning to this effect will ensue, but normal
    	execution should still be possible.

    	The Patch level no. may be left out totally from the numbering
    	convention. It is usually used just for a typo or small bug
    	fix in the library code.

    	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 -O2 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. If you want to
    	strip a binary, but don't have the source handy to use the
    	"-s" flag with ld. You can also use the "strip" command. See
    	"man strip" for more information.

    	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 question (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. Linux can optimize the
    	swapping of sharable (clean) pages by simply "forgetting" them -
    	because it can always reload them directly from the file.
    	Otherwise, it has to physically write them into the swap partition or
    	swap file - which needs some time and uses up disk space.

    	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 cleanly. If you start to run out of memory, the kernel can
    	start to delete unused code pages from demand pages executables as
    	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.
    	Debugging still works with -g on for some files only (the ones, which
    	are buggy).  More important than using the -g flag is to *not* use
    	the -fomit-frame-pointer flag, as it cheats gdb severly.
    	Unfortunately, the shared libs are usually compiled with
    	-fomit-frame-pointer for performance.

    	Therefore, it is wise, to give the -g or the -static flag to the
    	linker, to link with the non-shared libs, when debugging.  If you
    	fail to do so, you are usually unable to do a backtrace, when you
    	are caught with a segmentation violation in a system routine.

    	If you end up at the linker stage with a message like
    		Can't find libg.a
    	then you need to get it from the file
    		tsx-11.mit.edu: /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. However, you will not be able to debug any
    	of the library calls unless you use the full libg.a (~2Mb).

    	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:
    		prep.ai.mit.edu:/pub/gnu/gdb-4.11.tar.gz

    	A Linux precompiled version may be found at:
    		sunsite.unc.edu:/pub/Linux/devel/debuggers/gdb-4.11-bin.tar.gz

    	An X debugger based on this, (i.e. you need gdb installed first), is
    	also available. The source may be found at
    		ftp.x.org:/contrib/xxgdb-1.06.tar.Z

    	Also, the UPS debugger has been ported by Rick Sladkey. It runs
    	under X as well, but unlike xxgdb, it is not merely an X front end
    	for a text based debugger. It has quite a number of nice features,
    	and if you spend any time debugging stuff, you probably should
    	check it out. The Linux patches for UPS can be found at:
    		sunsite.unc.edu:/pub/Linux/devel/debuggers/ups-2.45.2-linux-0.1.diff.gz
    	You will need to get the full sources from your nearest X archive or
    		ftp.x.org:/contrib/ups-2.45.2.tar.Z

    -------------------------------------------------------------------------------

    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 no.
    	that you want to debug. Use the `attach' command to do this. GDB's
    	integrated online help is useful here.

    	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-as.tar.gz

    -------------------------------------------------------------------------------

    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.

    		% ldd /bin/init
    	gives no output meaning init was linked statically. And a good thing
    	too it was linked statically :-) (NOTE: For programs linked with
    	libc.so.4.5.10 and above, the message "statically linked" will be
    	output in this case)

    		% 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, depending on the version of libc you binary was originally
    	compiled with.

          *	Initially LD_LIBRARY_PATH was supported with libraries > than 4.3.3.

    	I.e. the __load.o routine in your stub (/usr/lib/libc.sa) was
    	replaced to cater for this. With binaries compiled using libc version
    	less than 4.4.4, linux's dynamic linker included the loader as 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.

    	compiled using library versions greater that 4.3.3, (libc.so.4.3.4
    	and above), but the upshot is that you will not notice it unless you
    	recompile *all* your binaries.

          *	With libc version 4.4.4 and above, the dynamic loader was infact made
    	dynamic and loads and unloads itself after searching and locating
    	the required libraries. The upshot of this is that binaries are
    	smaller and any changes to the dynamic loader/linker are isolated
    	from libc. You will need to read the manpages to ld.so and ldconfig
    	from the ld.so package. See question (4) under libld.so.

    	Linux's LD_LIBRARY_PATH is very security concious, and do NOT expect
    	to work the way Sun-OS do it or the way you'd like it to.

    	Primarily the difference with Sun-OS's LD_LIBRARY_PATH use is the
    	fact that during compilation (linking) stage, the LD_LIBRARY_PATH is
    	parsed to find valid libraries to link to and these are *recorded*
    	within the incomplete binary produced. Hence at runtime the binary
    	knows where to look for the shared libraries before it looks up
    	LD_LIBRARY_PATH, (and often it never parses LD_LIBRARY_PATH at all,
    	as it finds the shared libraries first in the recorded path), thus
    	reducing overhead. Linux on the other hand does NOT record this
    	information, but instead searches at runtime (execution) for
    	libraries it need to link to.

    	When a binary is executed on Linux it first searches /usr/lib, then
    	/lib and then / for a library to runtime link to if you do *not*
    	have any LD_LIBRARY_PATH. This can be referred to as the "trusted
    	search path".

    	Note that / is not really a search path, but was put in for
    	backward compatability as some users were building shared DLL's
    	using names like "/lib/libfoo.so" so uselib() would now do

    	So don't actually put your DLL's in / :-)

    	Now if you *do* have a LD_LIBRARY_PATH and you are root, (user with
    	uid 0), then LD_LIBRARY_PATH is searched followed by the trusted
    	search path.

    	If on the other hand you are a normal user, (uid != 0), and the
    	binary to be executed is a suid executable, then the libc.so.x and
    	necessary libraries are force loaded from somewhere in the trusted
    	search path. The LD_LIBRARY_PATH is ignored, (in fact reset totally).
    	This stops a normal user from emulating his own, for example, setuid()
    	calls from a libc library (s)he created.

    	Finally if you are a normal user and the binary to be executed is a
    	"normal" binary, then LD_LIBRARY_PATH is searched first for the
    	libraries required.

    	If the library is NOT found in the users LD_LIBRARY_PATH then the
    	search path is set to the "trusted search path" and the search
    	carries on. This gets over the problems of incorrect/silly
    	LD_LIBRARY_PATH settings and still allows these kind of nubile users
    	to execute binaries.

    -------------------------------------------------------------------------------

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

    Ans:	cpp appears in /usr/lib/gcc-lib/i486-linux/2.5.7
    	(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/i486-linux/2.5.7/cpp

    	** Change the 2.5.7 to whatever version of GCC your are using.
            ** Change the i486 to i386 if using the 386 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.5.7/include
    	<varargs.h> is K&R stuff. By default, gcc is ANSI. <stdarg.h> should
    	be used instead.

    	** Change the 2.5.7 to whatever version of GCC your are using.
    	** Change the i386 to i486 if using the 486 compiler

    -------------------------------------------------------------------------------

    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

    	The MCC release does not initially have these links, and hence
    	one can install a new kernel source tree, and still be using
    	the old include files. Watch out for this.

    -------------------------------------------------------------------------------

    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 though, 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 the future only `make' need be called to provide a working
    	executable.

    	One of the most frequent problems is 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().

    	There is another common problem: "sprintf(string, fmt, ...)" returns
    	a pointer to string on most unixes, while linux returns the number
    	of characters, which were put into the string.

    	Other problems tend to arise from the fact, that GCC is an ANSI
    	compiler. Most important changes are for the preprocessor.  Adding
    	the option:

    		-traditional

    	is often the only (but poor) solution.

    	| Some other worthy comments are noted below from Bruno Haible: |

    	This is an attempt to describe some of the problems that may arise
    	when porting Unix software to Linux.

    	We assume the software is written in C.

    	Linux (i.e. its system calls and C library functions) is as closely
    	POSIX compliant as possible. This makes this list very short.

    	Problem 1: The select() timeout
    	-------------------------------

    	Symptom:
    	A program that should only poll for input becomes a CPU hog.

    	Problem:
    	The select() system call. The timeout parameter was classically used
    	read-only by the system. Some manual pages already notes three years
    	ago:

    	       select() should probably return the  time  remaining  from
    	       the  original timeout, if any, by modifying the time value
    	       in place.  This may be implemented in future  versions  of
    	       the system.  Thus, it is unwise to assume that the timeout
    	       pointer will be unmodified by the select() call.

    	If you do not take this advice seriously you get a zero timeout
    	written back to your timeout structure, which means that future
    	calls to select() using the same timeout structure will immediately
    	return.

    	Fix:
    	Put the timeout value into that structure every time you call select().
    	Change code like

    	       struct timeval timeout;
    	       timeout.tv_sec = 1; timeout.tv_usec = 0;
    	       while (some_condition)
    	         { select(n,readfds,writefds,exceptfds,&timeout); }

    	to

    	       struct timeval timeout;
    	       while (some_condition)
    	         { timeout.tv_sec = 1; timeout.tv_usec = 0;
    	           select(n,readfds,writefds,exceptfds,&timeout);
    	         }

    	Problem 2: Interrupted system calls
    	-----------------------------------

    	Symptom:
    	When a program is stopped using Ctrl-Z and then restarted - or in
    	other situations that generate signals: Ctrl-C interruption,
    	termination of a child process etc. - it complains about
    	"interrupted system call" or "write: unknown error" or things like
    	that.

    	Problem:
    	The system call the program was executing has been interrupted to
    	process the signal, and then it returned -1 and set errno = EINTR.
    	The program then was likely to draw bad conclusions from that.

    	Explanation:
    	Your program has signal handlers installed (using signal(),
    	sigaction() or sigvec()). The signal occurred, and your signal
    	handler was invoked. In other Unix systems, this usually happens
    	asynchronously or in a few slow system calls:

    	  When a signal is caught during the execution of system calls such
    	  previously stopped or zombie process already exists, the
    	  signal-catching function is executed and the interrupted system
    	  call then returns a -1 to the calling process with errno set to
    	  EINTR.

    	Linux (following POSIX) checks for signals and may execute
    	signal handlers
    		* asynchronously (at a timer tick),
    		* on return from *any* system call,
    		* during the execution of the following system calls:
    		  select(),
    		  pause(),
    		  connect(), accept(),
    		  read() on terminals or sockets or pipes or /proc files,
    		  write() on terminals or sockets or pipes or line printer,
    		  open() on FIFOs or PTYs or serial lines,
    		  ioctl() on terminals,
    		  fcntl() with command F_SETLKW,
    		  wait4(),
    		  syslog(),
    		  any TCP or NFS operations.
    	  [For other operating systems you may have to include the system calls
    	   creat(), close(), getmsg(), putmsg(), msgrcv(), msgsnd(), recv(),
    	   send(), wait(), waitpid(), wait3(), tcdrain(), sigpause(),
    	   semop() to this list.]

    	In the last two cases and assuming the program's signal handler
    	returns, the system call returns -1 and sets errno to EINTR.

    	If the SA_RESTART flag is set for the corresponding signal, however,
    	in most cases the system call is automatically restarted (continued)
    	after execution of the signal handler, and your program won't see
    	any EINTR.

    	You may ask why this is not the default behaviour. This is because
    	returning and setting EINTR is more powerful: it gives your program
    	the opportunity to immediately react on every signal it receives.
    	System calls are no longer "dark tunnels".

    	Note that in some versions of BSD Unix the default behaviour is to
    	restart system calls. To get system calls interrupted you have to
    	use the SV_INTERRUPT or SA_INTERRUPT flag.

    	You may choose between two fixes.

    	Fix 1:
    	For every signal handler that you install, add SA_RESTART to the
    	sigaction flags. For example, change

            	signal (sig_nr, my_signal_handler);

    	to

            	 signal (sig_nr, my_signal_handler);
    	         { struct sigaction sa;
    	           sigaction (sig_nr, (struct sigaction *)0, &sa);
    	         #ifdef SA_RESTART
    	           sa.sa_flags |= SA_RESTART;
    	         #endif
    	         #ifdef SA_INTERRUPT
    	           sa.sa_flags &= ~ SA_INTERRUPT;
    	         #endif
    	           sigaction (sig_nr, &sa, (struct sigaction *)0);
            	 }

    	Note that while this applies to most system calls, you must still check
    	for EINTR on read(), write(), ioctl(), select(), pause(), connect().
    	Here are two examples for read() and ioctl(),

    	Original piece of code using read()

            	 int result;
    	         while (len > 0)
    	           { result = read(fd,buffer,len);
    	             if (result < 0) break;
    	           }
    	becomes

    	         int result;
    	         while (len > 0)
    	           { result = read(fd,buffer,len);
    	             if (result < 0) { if (errno != EINTR) break; }
    	           }

    	and;

    	Original piece of code using ioctl()

    	         int result;
    	         result = ioctl(fd,cmd,addr);

    	becomes

    	         int result;
    	         do { result = ioctl(fd,cmd,addr); }
    	            while ((result == -1) && (errno == EINTR));

    -------------------------------------------------------------------------------

    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 one or more of the relevant USENET newsgroups

    	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 is in releases of gcc for Linux versions gcc-2.4.0 and
    	above. This is not currently fully tested at the moment. The latest
    	version may be obtained from
    		tsx-11.mit.edu:/pub/linux/packages/GCC/gcc-2.5.7-p2.tar.gz

    -------------------------------------------------------------------------------

    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 `cc1' got corrupted due to a
    	race condition and bad blocks on my hard disk. There have also been
    	reports that overheating chips, (not french fries), can also produce
    	such errors. And watch for poor IDE controller/drive combos that
    	are being run faster than the standard 8MHz AT bus clock. These
    	can give the same errors by causing corruption of the swap space.

    	Usually, a signal 11 (segmentation violation) means that a process
    	tried to access memory out of its process space, or tried to write
    	into a read-only location.  Sometimes, this signal is caused by
    	software bugs, not by hardware faults (or your system would hang
    	repeatedly, because the same thing happened to the kernel).  With
    	gcc 2.3.3, some people could reproduce a lot of "signal 11"'s.

    	Also it can mean a failure in one of the `ld' or `as' stages. Try
    	recompiling whatever with a -v flag to gcc and see if it is failing
    	in one of the cc1, cpp, as or ld stages possibly.

    -------------------------------------------------------------------------------

    31) What is a libc.lite ?

    Ans:	A libc.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.

    	You may also have to change the source a bit, as the "crypt()" in
    	the shadow support is implemented as a macro and not a function.
    	Hence any "extern int crypt()" may trip it up.

    	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...

    	Always put the -lm flag after the objects. So this is no good:
    		% gcc -lm -o math_prog math_prog.c
    	as the math functions will not be resolved. Instead do:
    		% gcc -o math_prog math_prog.c -lm

    -------------------------------------------------------------------------------

    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

    	If you want a full printed manual for GCC, then you will have
    	to get the full source from your local ftp site that carries GCC
    	and other FSF goodies. You will require TeX to make the manual from
    	the GCC source distribution.

    	If it is the library function calls you are looking for, then you
    	need to get the full source for glibc. This will be on the same
    	ftp archive that you found the sources for GCC. Again, you will
    	need TeX to generate the manual. Be warned that this manual is
    	about 900 pages long. Save a tree and keep it online as a dvi file.

    	Both of the above packages also come with "info" files, that can be
    	viewed using Gnu info, xinfo, or emacs. "info" files are a hyper-
    	text based information system.

    -------------------------------------------------------------------------------

    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)

    -------------------------------------------------------------------------------

    36) If I upgrade versions, can I get rid of the old stuff from /usr/lib/gcc-lib/i[34]86-linux/<old-version> ?

    Ans:	Well unless you are testing gcc releases it is fairly safe to get
    	rid of any older versions in that directory. You can compile with
    	older versions of gcc using "gcc -V <old-version>

    -------------------------------------------------------------------------------

    37) [HELP] where is libipc.a ? Needed for dosemu 0.49..

    Ans:	The Inter Process Communication (IPC) functions are included as
    	standard in libc as of libc.so.4.4.1. This means if you have
    	libc.so.4.4.1 and above, you do not need -lipc and can remove this
    	line from the Makefile. If you do not have libc.so.4.4.1 and its
    	related stub libc.sa then you need to upgrade you libraries.

    -------------------------------------------------------------------------------

    38) XXX won't compile: _daemon undefined, help!!

    Ans:	daemon() is in libbsd.a. Just add -lbsd to your Makefile LDFLAGS line.

    -------------------------------------------------------------------------------

    39) [HELP] ar and libraries. Linking fails although symbol appears in library.

    Ans:	There is a known bug in `ar' where sometimes `ranlib' does not
    	generate a correct table. This can be worked around with the
    	commands

    		% ar -dv libfoo.a __.SYMDEF
    		% ranlib libfoo.a

    -------------------------------------------------------------------------------

    40) HELP! newbie gets warning message "libc.so.4: incompat. minor ver no."

    Ans:	You need a shared library upgrade. See questions (12) and (3) for more
    	details.

    -------------------------------------------------------------------------------

    41) Where can I find `lint' to check my c programs before compilation ?

    Ans:	There is no `lint' or the likes for checking programs. Instead use the
    	plethora of gcc options for checking your programs. Read the manual
    	pages for the variety options.

    	The most useful

    		% gcc -Wall foo.c

    	will warn you of most of the possible problems that might occur.

    -------------------------------------------------------------------------------

    42) My program needs sgtty.h where is it ?

    Ans:	It is in /usr/include/bsd directory. So just add the line

    		-I/usr/include/bsd

    	to your CFLAGS line in the Makefile when compiling.

    -------------------------------------------------------------------------------

    43) How do I stop or start core files being produced on SIGSEGV's ?

    	to stop core files being produced totally:

    		In C-shell `csh' (tcsh)
    			% limit core 0
    		In Bourne shell `sh' (bash)
    			% ulimit -c 0

    	To start corefiles when you recieve signal 11 (SEGV):

    		In C-shell `csh' (tcsh)
    			% limit core unlimited
    		In Bourne shell `sh' (bash)
    			% ulimit -c unlimited

    -------------------------------------------------------------------------------

    44) What does the message "can't load dynamic linker `/lib/ld.so'" mean ?

    Ans:	This means you haven't installed the dynamic linker/loader. See
    	question (4) under libld.so on where to obtain this from.

    -------------------------------------------------------------------------------

    45) What is the difference between -O2 and -O6 optimizations ?

    Ans:	Nothing at present. If you look at the source code for
    	GCC (eww! yuck!) with an i386/i486 host/target, you will see
    	that -Ox for x>=2 does the same thing. In fact it is a bad
    	thing to use x>2 in your Makefiles, because if GCC implements
    	-O3 on Intel targets in the future, it may be an optimization
    	that breaks your code.

    -------------------------------------------------------------------------------

    46) How can I check an unknown binary to see if it is a trojan horse ?

    Ans:	First, if you are worried that it is going to hose your machine,
    	*don't* run it. (At least not as root!) Try and find the source
    	and recompile it. Other than that, you might be able to get some
    	information on it by typing "strings <filename> | less". If you
    	are game enough to run it, you can use "strace" to see if it
    	is doing anything nasty.

    -------------------------------------------------------------------------------

    47) Where are the sources to the C library - how do I rebuild it ?

    Ans:	Look in
    		tsx-11.mit.edu:/pub/linux/pagkages/GCC/libc-4.5.8.tar.gz

    	If you want shared libraries you will also need the dll tools package.
    	See question (5) on where to obtain this from.

    -------------------------------------------------------------------------------

    48) Where are the definitions of FD_* stuff ?

    Ans:	Just include <sys/time.h> and these macros will be included.

    -------------------------------------------------------------------------------

    49) When linking with option -g I get undefined ___fpu_control and ___setfpucw ?

    	/usr/lib/crt0.o Undefined symbol ___fpu_control reference from text segment.
     	/usr/lib/crt0.o Undefined symbol ___setfpucw reference from text segment.

    	what's wrong?

    Ans: 	You have updated your crt0.o libc.sa and libc.a from a recent copy
    	of the linux libc, but you have still an old libg.a around.

    	If you really want to get a static binary (this is implied by -g)
    	with a debug library, you should get and install libg.a.
    	See question (15) on the whereabouts of this.

    -------------------------------------------------------------------------------

    50) Where can I get the tools to Internationalize my library/application ?

    Ans:	Get the file
    		sunsite.unc.edu:/pub/Linux/utils/nls/cat-pack.tar.gz
    	and follow the instructions there.

    	User contributed catalogs in various languages may be found in
    		sunsite.unc.edu:/pub/Linux/utils/nls/catalogs
    	and placed in the Incoming directory under there.

    	NOTE: Internationalization tools and functions are only available in
    		libraries greater than version 4.4.4 (i.e. libc.so.4.5.x and
    		above)

    	NOTE: In this context `Internationalization' is used loosely and as of
    		linux pl14 supports only Latin-1/ISO-8859-1 charsets.

    -------------------------------------------------------------------------------

    51) The DLL tool `mkimage' fails with to find libgcc. Help!!!

    Ans:	As of libc.so.4.5.x and above, libgcc is no longer shared. Hence you
    	must replace occurences of `-lgcc' on the mkimage line with

    		`gcc -print-libgcc-file-name`

    	or for short

    		`gcc --print`

    	With the backquotes intact.

    -------------------------------------------------------------------------------

    52) How do I get rid of "__NEEDS_SHRLIB_libc_4 multiply defined" messages ?

    Ans:	As of libc.so.4.5.x and above, libgcc is no longer shared. Thus you
    	MUST delete all /usr/lib/libgcc* files.

    		% rm -f /usr/lib/libgcc*

    -------------------------------------------------------------------------------

    53) What is this QMAGIC thing everyone is talking about ?

    Ans:	QMAGIC is an executable format just like your standard a.out (which
    	are ZMAGIC) binaries, but which leaves the first page unmapped. This
    	allows for easier NULL dereference trapping as no mapping exists in the
    	range 0-4096. As a side effect your binaries are nominally smaller
    	as well (~1K).

    	Your `file' command will be able to identify a QMAGIC binary if the
    	proper entry has been added to your /etc/magic file. I have
    	distributed suitable entries to most channels.

    -------------------------------------------------------------------------------

    54) How do I generate a QMAGIC executable/library ?

    Ans:	You need the lastest `ld' binary or patches to the source to be able
    	to generate QMAGIC executables. This will be distributed in the
    	`binutils-as.tar.gz' file - See question (6).

    	To build a QMAGIC executable:

    	  Add one of the following to your LDFLAGS line in the Makefile
    		LDFLAGS = -Wl,-qmagic
    	  or
    		LDFLAGS = -Xlinker -qmagic

    	To build a QMAGIC library:

    	  Sorry, not fully supported by the `mkimage' tool at the moment.

    -------------------------------------------------------------------------------

    55) Is it possible to turn the "warning using incompatable library version xxx" messages off ?

    Ans:	Yes.
    	If you have ld.so version 1.4 and above you may set the environment
    	variable LD_NOWARN to supress warning messages. Note: fatal mesages
    	are still output.

    	In csh (tcsh):
    		setenv LD_NOWARN
    	In sh (bash):
    		export LD_NOWARN=1

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

                           Acknowledgements: (in no order)

                                      H.J.Lu
                                   Dirk Hohndel
                                    David Engel
                                  Eric Youngdale
                                 Bill Metzenthen
                                    Rik Faith
                                  Steven S. Dick
                                   Bruno Haible
                                   Andrew Tefft
                                    Kai Petzke
                                  Tuomas J Lukka
                                 Fergus Henderson
                                  Paul Gortmaker
                                   Olaf Flebbe
                                  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. Email me and I will rectify it.

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

    Please help in making this FAQ the definitive answer repository of Linux GCC
    and additions to me

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