[LCP]stdio.h reference

ianezz at sodalia.it ianezz at sodalia.it
Tue Jan 8 02:35:44 UTC 2002


Madhav M., pigiando tasti a caso sul citofono, ha scritto:

 > I want to know, how linker reolves the reference for stdio.h.  I
 > chekced /etc/fstab file and also checked LD_LIBRARY_PATH. But i
 > didnt get the path for stdio.h.  Am I missing something???

The linker has nothing to do with preprocessor directives.

``#include <stdio.h>'' is a directive telling the C preprocessor to
 substitute that directive with the content of a file named stdio.h.

The preprocessor looks for that file in a set of directories:

 - first, all the ones specified on the command line with the
   -I<directory> options

 - then a set of common directories like /usr/include and the compiler
   installation directory
   (i.e. /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include)


Also, if you specify the name of the file between double quotes
instead of angular parenthesis, as in

   #include "stdio.h"

the first directory searched by the preprocessor for that file is the
one containing the file being preprocessed.

The preprocessor includes the files, expand the macros, strips
comments, and then send the output to the compiler. 

The compiler in turns generates the assembly code for the target
platform, and that is passed to the assembler.

The assembler in turns generates an object file containing the
machine-excutable code, data and other structures needed by the
linker.

This has to be done for each C source file in your
application/library, so unless you have only one C source file, you
end with several object files.

These can be grouped in an archive library (.a) using the `ar' and
`ranlib' tools, so they can be used later for other programs (i.e. if
you want to make a library). 

Or they can be passed to the linker to produce either an executable,
or a dynamic library (.so, or .sl on some systems).

The linker takes one or more object files and zero or more libraries
(either archive ones or shared ones), solves the cross-references
between the various pieces of the code and then generates either an
executable or a shared library.

When you generate an executable, some options are implicit: i.e. you
don't have to explicitly specify to link the C standard library and
the startup and exit code for your program, because this is implicit. 

Instead, you may want to specify additional libraries, using one or
more options in the form of ``-L<directory>'', which tell the linker
where to search for libraries in addition to the standard directories
(like /usr/lib and the compiler installation directory), and one or
more options in the form of ``-l<library>'' which tell the linker
which libraries have to be linked in.

You can see the output of the various stages. Given you have your
program ``sample.c'':

1) you can see the preprocessor output with 

   gcc -E sample.c | less

2) you can see the assembly generated by the compiler with

   gcc -S sample.c; less sample.s

3) you can see the object file generated by the assembler with

   gcc -c sample.c -o sample.o

4) you can have your executable either with

   gcc sample.c -o sample

   or with the two lines

   gcc -c sample.c -o sample.o
   gcc sample.o -o sample

--
UNIX diapers by Pannolini USPTO 2039887  http://www.uspto.gov
Matteo Ianeselli      ianezz AT sodalia.it  (+39) 0461 316452
Visita il LinuxTrent:            http://www.linuxtrent.it



More information about the linuxCprogramming mailing list