------------------------Linux GCC FAQ 22nd May 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 are <float.h>, <limits.h>, <varargs.h>, <stdarg.h> and <stddef.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,4" 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 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 ?
56) Is GNU's glibc 1.06 texinfo manual pages relevant to Linux's libc?
57) Can I sell my application if it was compiled within linux ??
58) Why do I get an "Assertion failure" message when rebuilding a DLL ??

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

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

	Other GCC, C, C++, g++, Objective-C, FAQ's may be found at

		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.8/specs
		gcc version 2.5.8
	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.8/specs
		gcc version 2.5.8
	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.8 and available from
		tsx-11.mit.edu:/pub/linux/packages/GCC/gcc-2.5.8-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.26.tar.gz

	The latest `as', `ld', `ar' etc may be found in the package
		tsx-11.mit.edu in /pub/linux/packages/GCC/linux-binutils-1.0.tar.gz

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

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

Ans:	See question (4) below. You need the file image*.tar.gz.
	Only 486 images are provided (they work also on 386's - but the
	image size is slightly larger). You will need to recompile the shared
	libraries if you want 386 libaries. See question (47) on where to
	obtain the source code to the linux C library

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

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.26.tar.gz
libm.so			included in above tar.gz file.

libX11.so	tsx-11.mit.edu:pub/linux/packages/X11/XFree86-2.1/XF86-2.1-lib.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.2.tar.gz
libgr.so	sunsite.unc.edu:/pub/Linux/libs/graphics/libgr-1.3.tar.gz
libf2c.so	sunsite.unc.edu:/pub/Linux/devel/fortran/libf2c-0.9.2.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/X/libXpm-3.4a.tar.gz

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

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.1/XF86-2.1-pex.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	sunsite.unc.edu:/pub/Linux/X11/devel/iv-3.1l.2.tar.gz
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/ld.so-1.4.3.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.6-bin.tar.gz

libvga.so	sunsite.unc.edu:/pub/Linux/libs/graphics/svgalib111.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/Xaw3d-0.6B.3.1.1.bin.tar.gz
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:
    1) Shared+Static Motif library
    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 
(305) 970-7353 (voice) or (305) 970-7351 (fax) or by mailing us 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
 Voice: +1.305.970.7353    Fax: +1.305.970.7351  Email: mahesh@metrolink.com
            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

		tsx-11.mit.edu:/pub/linux/packages/GCC/src/tools-2.11.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-1.9l.3-as-2.2l.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" \
			tooldir=${LBINS}.. LANGUAGES="c c++ objc"

	   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.11.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.8/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.

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

	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 (~2.7Mb).

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

	A Linux precompiled version may be found at:
		sunsite.unc.edu:/pub/Linux/devel/debuggers/gdb-4.12-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.08.tar.gz

	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 precompiled version and patches for the stock
	UPS sources can be found at:
		sunsite.unc.edu:/pub/Linux/devel/debuggers/ups-2.45.2-linux-0.1.tar.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
	if you wish to rebuild it yourself

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

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

		sunsite.unc.edu:/pub/Linux/devel/strace/strace-2.tgz

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

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-1.9l.3-as-2.2l.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.

	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 :-) (NOTE: For programs linked with
	libc.so.4.5.19 and above, the message "statically linked" will be
	output in this case) 

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

	So to answer the question is, Yes, it is supported if anything is
	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

		(1) uselib("/usr/lib//lib/libfoo.so.x")  ---- fails 
		(2) uselib("/lib//lib/libfoo.so.x")      ---- fails again
		(3) uselib("//lib/libfoo.so.x")          ---- succeeds.!!

	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.8
	(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.8/cpp

	** Change the 2.5.8 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 are <float.h>, <limits.h>, <varargs.h>, <stdarg.h> and <stddef.h> ?

Ans:	These files depend on the version of your compiler. Theyfore they are 
	hidden in a compiler directory.
		/usr/lib/gcc-lib/i486-linux/2.5.8/include

	** Change the 2.5.8 to whatever version of GCC your are using.
	** Change the i486 to i386 if using the 386 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
	  as read(2), write(2), open(2) or ioctl(2) on a slow device (such
	  as a terminal, but not a file), during a pause(2) system call or a
	  wait(2) system call that does not return immediately because a
	  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;
        	     buffer += result; len -= result;
	           }
	becomes

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

	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

		gnu.gcc.bug, gnu.gcc.help, gnu.g++.help,
		comp.lang.c, or comp.lang.c++.

	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.8-p2.tar.gz

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

30) What does the message "Internal compiler error: cc1 got fatal signal 11,4" 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.

	A "fatal signal 4" has been reported to be generated due to lack of
	memory (happened on a 4MB system).

	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.

	NOTE: At some point in the future the shadow routines may be
	integrated into the standard C library.

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

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

	This file contains the man pages cccp.1, cpp.1, g++.1 and gcc.1.

	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 ?

Ans:	This is not really a GCC question, but more a shell one. Anyhow
	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. See question (17) on its whereabouts.

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

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

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

	To rebuild, unpack the sources, make sure you have the corresponding
	include files for that version of the C library, and then under
	libc-linux directory do the following

		% ./configure

	Answer all the questions at this point. If you are building on a 
	native linux machine (i.e not cross-compiling) you can just type
	<return> at this point (i.e. accept the default values). Then type

		% make

	NOTE: If you are cross-compiling, it is probably a wise idea to keep
	a copy of the configure generated file `config.in' for future use.
	You can just copy the old version into the libc-linux directory and
	type `make'.

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

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 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-1.9l.3-as-2.2l.tar.gz' file - See question (2).

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

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

56) Is GNU's glibc 1.06 texinfo manual pages relevant to Linux's libc?

Ans:	Yes, except for the stdio internals.

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

57) Can I sell my application if it was compiled within linux ??

	(a) It is legal to sell your applications.  You may take as much
	    money as you want.

	(b) Simply using a GNU tool to develop your application does not
	    affect your copyright to your applications.  This includes
	    using g++ and gcc.

	(c) However, your copyright is affected, if you include code from
	    other GNU applications into yours.  In this case, you have
	    to put the resulting ("derived") work under the GNU copyleft.
	    That means, that you have to release source code upon request,
	    and that your customer(s) may distribute (and/or sell!) copies
	    of your source code and/or binary.

	(d) 99% of all C programs written are linked against the C
	    library.  Linking means, that you include GNU code into
	    your program.  However, the C library is released under
	    special terms (GNU Library Public License, GLPL), which
	    allows linking as an exception to what is said in c).

	    You can link with the C library at will, but you have to
	    provide your program in a form, that the user can update
	    the library.  In case of shared linking, this is not a
	    problem, but if you want (or must) link with static
	    libraries, you must provide your program in a form, which
	    has not yet been linked with the static library (say, link
	    all your .o-files into one big .o using "ld".  Take a look
	    at the kernel sources to see how it works).

	(e) What is said at point a) is always true: you may sell your
	    application, whether or not it has to be distributed under
	    the GNU copyleft, for as much money as you want.

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

58) Why do I get an "Assertion failure" message when rebuilding a DLL ??

Ans:	This cryptic message most probably means that one of your jump
	table slots has overflowed because too little space has been
	reserved in the original jump.vars file.

	You can locate the culprit(s) by running the `getsize' command
	provided in the tools-x.y.tar.gz package. See question (5) on where
	to obtain this from.

	The only solution in this case may be to bump up the major version
	number of the library forcing it to be backward incompatible.

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

                       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
queries by e-mailing questions, (and answers if you have them), corrections
and additions to me

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