-------Linux GCC FAQ 11th March 1995 (with preliminary ELF additions)-------

-------Linux GCC FAQ 11th March 1995 (with preliminary ELF additions)-------

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) Do 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 by 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 incompatible library version xxx" messages off ?
56) Are GNU's glibc 1.08 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 ??
59) Can I build DOS executables under linux ?
60) Is -fpic - i.e PIC (position independent code) supported on linux. ?
61) What is this ELF thing anyway ?
62) How do I build an ELF libc ?
63) Why does the execl() call fail on linux and just print out libc.so.4 messages ?
64) Can I preload objects with a.out binaries (a.la Sun LD_PRELOAD) ?
65) With the new gcc I cannot seem to generate ZMAGIC binaries ?
66) perl-5.00 needs dlopen() and friends. Where are they anyway ?
67) Where can I get more info about ELF ?

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

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

The latest `as', `ld', `ar' etc may be found in the package

tsx-11.mit.edu:/pub/linux/packages/GCC/binutils-2.5.2.6.bin.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-4.6.27.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-2.16.tar.gz 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.6.27.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-2.0.3.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.10.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.4c.tar.gz

libnsl.so ftp.lysator.liu.se:/pub/NYS/nys-0.27.1.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/libs/X/iv3.1dist.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.5.2.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.7l1-bin.tar.gz

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

libitcl.so sunsite.unc.edu:/pub/Linux/devel/tcl/itcl1.5l1-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/X/Xaw3d-0.6B.3.1.1.bin.tar.gz
and
sunsite.unc.edu:/pub/Linux/libs/X/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
[email protected].

==============================================================================
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: [email protected]
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.16.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:/pub/linux/packages/GCC/binutils-2.5.2.6.bin.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 files 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.4.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 an 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) That's 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.16.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.6.2/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 compatibility
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.
* Make the binary QMAGIC - Use the -qmagic flag at the ld stage -
See question (53) for building QMAGIC executables.

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, see question (28)) *OR* if 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.

Note with newer `ld' executables QMAGIC is the default for the
a.out format.

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

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 page 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' severely.
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.6.27.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.13.tar.gz

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

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

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-2.5.2.6.bin.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). For statically linked ELF executables you will
get the message "statically linked (ELF)".

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'. For dynamically linked ELF executables you will
get a messages like (paths may be different)

Linux ELF dynamic linker: gs: file loaded: /usr/X386/lib/libX11.so.4
Linux ELF dynamic linker: gs: file loaded: /usr/lib/libm.so.4
Linux ELF dynamic linker: gs: file loaded: /usr/lib/libc.so.4

Note: For ELF executables you MUST be using a `ldd' or `ldconfig'
from the ld.so package (See question (4)) version 1.5.0 or greater
for this to work.

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

20) Does Linux have support for LD_LIBRARY_PATH ?

Ans: Yes and No, depending on the version of libc your 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 contains 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: 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 in fact 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
it 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 needs 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 compatibility 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 user's 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.6.2
(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.6.2/cpp

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

A possible alternative is this:

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

This way /lib/cpp won't stop working when you switch to a newer gcc
version and delete the old one. However the former command (i.e the
link) will read from stdin, while the latter will complain about a
missing filename argument (unless you explicitly specify - as stdin).
Any program that uses /lib/cpp as a filter without any arguments
will therefore fail. For example "xrdb" won't work (the error is
silently ignored).

Because of these differences, it is advisable to remember to update
the link instead.

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

22) Where are <float.h>, <limits.h>, <varargs.h>, <stdarg.h> and <stddef.h> ?

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

** Change the 2.6.2 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 page already noted 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 ([email protected]) the writer of the
emulator code.

Finally you could try emailing [email protected], myself
([email protected]) 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.
With a.out DLL's you can also strip them after building as the
address's are in fixed locations. Do not attempt to strip ELF
libraries.

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

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

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

An ELF library does not have a corresponding stub as all the exported
data is in the shared object.

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

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.6.2-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're 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) Do 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/system/Admin/shadow-3.3.1.tar.gz
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), (3) and
(55) 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.

Alternatively a PD lint is available from

larch.lcs.mit.edu:/pub/Larch/lclint

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

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 receive 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.6.27.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 (european) and
KOI-8 (russian) locales.

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

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 occurrences of `-lgcc' on the mkimage line with

`gcc -print-libgcc-file-name`

or for short

`gcc --print-libgcc`

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
then 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 latest `ld' binary or patches to the source to be able
to generate QMAGIC executables. This will be distributed in the
`binutils-2.5.2.6.bin.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:

Supported with the `mkimage' tool from the tools-2.16.tar.gz package
onwards you may use the "-qmagic" flag to the linker on the
"mkimage" command line.

Note that with newer versions of `ld', QMAGIC is the default a.out
format. ZMAGIC executables are no longer supported (although they
will succesfully run).

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

55) Is it possible to turn the "warning using incompatible 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 suppress warning messages. Note: fatal mesages
are still output.

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

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

56) Are GNU's glibc 1.08 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-2.16.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.

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

59) Can I build DOS executables under linux ?

Ans: Get a life !!
Anyway I have been told that it is somewhat possible by using the
"emx" package or the "go" extender.

Please look in

sunsite.unc.edu:/pub/Linux/devel/msdos

I have not tested this and cannot vouch for its abilities.

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

60) Is -fpic - i.e PIC (position independent code) supported on linux. ?

Ans: Yes but only with ELF executables. a.out PIC is not supported.
This is currently in the testing stage, but works very well.

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

61) What is this ELF thing anyway ?

Ans: This section is from the document '/news-archives/comp.sys.sun.misc'.

ELF ("Extensible Linking Format) is the "new, improved" object file
format introduced in SVR4. ELF is much more powerful than straight
COFF, in that it *is* user-extensible. ELF views an object-file as
an arbitarily long list of sections (rather than an array of fixed
size entities), these sections, unlike in COFF, do not HAVE to be in
a certain place and do not HAVE to come in any specific order etc.
Users can add new sections to object-files if they wish to
capture new data. ELF also has a far more powerful debugging format
called DWARF (Debugging With Attribute Record Format) - not currently
fully supported on linux (but work is underway). A linked list
of DWARF DIEs (or Debugging Information Entries) forms the .debug
section in ELF. Instead of being a collection of small, fixed-size
information records, DWARF DIEs each contain an arbitrarily long
list of complex attributes and are written out as a scope-based tree
of program data. DIEs can capture a large amount of information that
the COFF .debug section simply couldn't (like C++ inheritance graphs
etc.).

ELF files are accessed via the SVR4 (Solaris 2.0 ?) ELF access
library, which provides an easy and fast interface to the more gory
parts of ELF. One of the major boons in using the ELF access library
is that you will never need to look at an ELF file qua. UNIX file, it
is accessed as an Elf *, after an elf_open() call and from then on,
you perform elf_foobar() calls on its components instead of messing
about with its actual on-disk image (something many COFFers did with
impunity). ELF is now supported by GNU gdb-4.12 (and above) on linux
and many other tools and is definitely something to look forward to
in linux. You may compile gdb with
./configure i386-sysv-linuxelf

You may find more doccumentation (postscript) on version 1.1 of
ELF from

tsx-11.mit.edu:/pub/linux/packages/GCC/ELF.doc.tar.gz

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

62) How do I build an ELF libc ?

Ans: Get the libc sources (See question (47) on where to obtain it) and
then you simply need to do

% make ELF=true

after running

% ./configure

This is assuming you have installed the ELF gcc/ld/as etc.. as
indicated in question (60) above.

NOTE: This is only supported for libc versions 4.6.x

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

63) Why does the execl() call fail on linux and just print out libc.so.4 messages ?

Ans: The execl() call does NOT fail on linux. It basically means your
application does not strictly conform to POSIX.1. You have just not
read the manpage correctly and are not providing execl() with the
right parameters. Here is a quote from the manpage:

Two interfaces are available. execl() is useful when a
known file with known arguments is being called; the argu-
ments to execl() are the character strings constituting the
file and the arguments; the first argument is conventionally
the same as the file name (or its last component). A (char
*)0 argument must end the argument list. The cast to type
char * insures portability.

So your execl() should provide a *minimum* of two arguments like

execl("/bin/ls","ls",NULL);

instead of just

execl("/bin/ls", NULL);

The single argument execl() command is reserved for the use of
identifying the executable dependencies (i.e. its shared libraries)
or whether it is static.

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

64) Can I preload objects with a.out binaries (a.la Sun LD_PRELOAD) ?

Ans: Yes but only if you are using ld.so version 1.5.2 or above. See
question (4) under libld.so on where to obtain this from.

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

65) With the new gcc I cannot seem to generate ZMAGIC binaries ?

Ans: Well it's not really gcc but the new binutils which do not support
the creation of ZMAGIC binaries. Support will continue unhindered
for the execution of these binaries so old programs will still
be able to work.

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

66) perl-5.00 needs dlopen() and friends. Where are they anyway ?

Ans: dlopen() and friends are only supported in the ELF executable format.
ELF compiler and utilities will be available shortly. They are
undergoing final testing now (Dec `94). Perl-5.00 has been succesfully
built using ELF format with complete dynamic loading facilities.

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

67) Where can I get more info about ELF ?

Ans: Daniel Barlow has put up a URL describing some more detail about ELF.
Set your URL to the location

http://sable.ox.ac.uk/~jo95004/elf.html

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

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
Jens Schweikhardt
Bruce Evans
Axel Boldt

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 <[email protected]>