I'm somewhat new to programming. What I want to figure out is how functions from header files compile into a program. For instance, the header file
Has function prototypes for all the functions in stdio.h. What I don't understand is where the function definitions are and how they are compiled into the program using the header file. Thanks for any help.

> For instance, the header file stdio.h has function prototypes for all the functions in stdio.h.

True.

> What I don't understand is where the function definitions are

You usually don't get their sources, only the precompiled objects/libraries/shared objects/DLLs (platform dependent).

> and how they are compiled into the program using the header file.

They are linked into the program during the linkage.

your question is good , because i was also hammerd by this topic ! so for understanding this , see this example & please dont take this seriously because i understand this topic , with my own example and please try to co-operate with me !

An organized c or any language program with a real life example !

{your program}
header files !
&&
your code !

{now real life}
God !
&&
human !

now see , when ever god creates any human , god adds a rule for every human that he/she will get 2-eyes + 1-nose + 2-legs + 2-hands .... so these all things are added at top of the world !

so , now if any human takes birth , he/she will be the part of this process , and get "2-eyes + 1-nose + 2-legs + 2-hands"

so , rule is a , properties which are designed for humans but not defined !

now what is the difference ,

see you have 2 hands .... designed !
but
you can use them in eating .... defined !
you can use them in drinking .... defined !
you can use them in coding .... defined !

so here three types of works are assigned to your hand !

now please come back in your program !

you have stdio.h

<stdio.h> .... is a collection of , rules{hands} but , your program{human} knows that , i have rules , but it does hot know
how to use this hands , so these rules are checked at compile time that , your program have following properties or not , if not than compile time error , but if you have these properties , than they are added at run time !

// i think it will help you ! else ... sorry !

For a minute I thought I understood it. but now I'm confused again. I'm in a similar situation I'm a Programming noob my programs are finally graduating from the "hello world" phase, but I am so confused about includes and libraries.

I don't understand why the header file needs prototypes to functions in the same file? I was under the impression that the headers had something to do with referencing linked libraries. Is this wrong?

I guess this is what I'm confused about:

1. Whatever is in that header I don't understand what is going on. What exactly am I looking at? Are these pre-processor directives?

2. Does a header file directly have anything to do with pre-compiled libraries? Can you use a header without a library or a library without a header? or do they work together somehow?

3. I'm using the gcc compiler in linux. Is there a file or environment variable that gcc uses to locate include and library paths?

4. what are the differences between library extensions: .so, .a, .so.a

> I don't understand why the header file needs prototypes to functions in the same file?

The header provides function-prototypes (and structure-definitions, typedef's, #define's, comments etc) for other programs, it doesn't need them. It doesn't contain function-definitions either

> Does a header file directly have anything to do with pre-compiled libraries? Can you use a header without a library or a library without a header? or do they work together somehow?

Forget about libraries for a moment, and consider three files of a module called foo.

foo.h: header declaring what module foo exports
foo.c: source code of the module
foo.o: object code of the module

Now if you want to compile a program that uses foo, you will need foo.h; if you want to link that program, you will need foo.o. (You won't need foo.c at all.)

> I'm using the gcc compiler in linux. Is there a file or environment variable that gcc uses to locate include and library paths?

No, there are built in locations (eg: actual directory, /usr/include; /usr/lib, /lib) and the ones that are specified with option -I and -L
In non-trivial cases you use utility make.

> what are the differences between library extensions: .so, .a, .so.a
Well, it is a rather different topic...
.o: object
.a: library (set of objects)
.so: shared object/library
.so.a: there is no such thing

2 members found this post helpful.

Executable binaries as created by compilers, especially C/C++ compilers, are composed of object code from at least two or three kinds of places. There is the object code produced by compiling a source file, or files. There is the standard C library, in Linux, normally called libc.so. There is zero or more other libraries that may be from various third-parties or are part of the language/compiler, such as the floating point math library, libm.so. There is very little difference between the standard C library and all other libraries, except that the C compiler may specify library versions and fileystem locations of the standard C library in the object code it generates. The compiler has built-in knowledge of some aspects of the standard C library that it expects to use.

When you compile a source file, the compiler uses the declarations in the header files to understand what the declared functions will look like, when they are eventually linked to the program. It creates object code that contains references to those 'external' functions. You can generate multiple object modules by compiling multiple source files. To create the runtime executable binary object module, you link all of the object modules and libraries, using a linker. The linker pulls all of the parts together, resolving all of the 'external' references by associating them with the respective 'public' symbols (functions and global variables) contained in the set of libraries and object modules.

Prototypes for functions in one file are simply a form of a programmer's safety net. The compiler is more able to recognize when you have written something that is inconsistent. Header files contain standard C programming language source code. Organizationally, they usually perform the task of exposing public symbols, and that is why they are used to declare public functions. You can include redundant headers that only declare un-needed functions and other symbols quite harmlessly.

Object libraries may be actually linked at runtime, using shared-object libraries (libxxxyyy.so), or can be statically linked at build-time. Libraries for static linking are named like 'libxxxyyy.a'. When an executable is statically linked to all of its libraries, it can be executed without those libraries being present on the filesystem. Otherwise, the shared-object libraries must be present, and find-able by the linker, ld, on the filesystem.

For questions about the use of gcc on Linux, consult the man pages and/or the gcc website.

--- rod.

3 members found this post helpful.

> what are the differences between library extensions: .so, .a, .so.a
Well, it is a rather different topic...
.o: object
.a: library (set of objects)
.so: shared object/library
.so.a: there is no such thing

It's worth mentioning that .a is a static library while .so is a shared object. I found this page if anyone's interested: http://www.yolinux.com/TUTORIALS/Lib...ndDynamic.html

A header file contains (amongst other things) function prototypes,
these prototypes simply enable your compiler to check you are not making any silly errors with
how you call the functions. That's all really.

If you don't include them you can call the function anyway but
nothing will check you have called it in the correct way.
Basically a safety device.

The libraries are the real code, which are linked with your program to complete the whole picture.
i.e. add in the functions you want to use. Which are bolted on if you like.
(sometimes at run time sometimes at build time, though they are effectively identical)

Interesting.
Lately I've been working with openCV. The only includes I use are cv.h and highgui.h.
The most frustrating part about this is that it's fairly easy to code something that compiles, but upon running crashes and burns with crazy useless error messages.
Would this be an example of not using proper includes?

You still should try and read those crazy messages

if you compile with warnings -Wall it will give you a lot of clues.

If it's not core dumping you are probably OK regards headers.
Crazy error messages are a C++ speciality. Only java beats it!

Oh I do. Now that I am a little more familiar with what it wants I can generally get a good idea of the nature of the problem. The problem is that it doesn't give any hints to where in the code it might be. So as long as I'm recompiling and running my code after every change it's not too bad. Throwing in many of my own debugging messages also helps.

but that's really not what I'm getting at. I'm still trying to understand these headers and what exactly it is that they do. What bigearsbilly said, seems to make sense based on what I have observed. What I am wondering is why the compiler allows me to compile code which doesn't work. Is this something which could be an issue of incorrectly specified headers.

I'm speaking theoretically here, I'm not saying that there are more headers I should be adding or that the opencv library is poorly written. I'm simply trying to relate. Is the symptoms I'm describing something that could be seen when insufficient header information is included?

Did you use options -W -Wall -Werror -pedantic? Why not?

Welcome to the real world!

1 members found this post helpful.

Compiler will not try to run your code, so it cannot decide: probably it works, probably not. What a compiler can do:
1. syntax check: it will give a warning if you want to use something "strange", but compiler will try to guess and solve it by itself. It will give an error if it cannot understand the source file (it does not follow the rules of the language) and will drop a message about where it was lost.
In both cases the compiler will try to find the location of the problem and sometimes it cannot find...
2. compile, optimize, add debug info, link ...
3. The problems can be analyzed later with debugger or other tools, but the compiler itself will not help you in any way to solve them...