Thread: Rudimentary, but not obvious! (About .h files)

... where are the functions??? For example strcat

linked on a compile time to your app ( .a )
or used at runtime from ( .so )
depends you...

here's more...
http://users.actcom.co.il/~choo/lupg...libraries.html

Originally Posted by Axpen

Code:

char*	strcat (char*, const char*);

Ok, now that part certainly makes since to me as a declaration, how ever, how does the compiler know what to do with the arguments with nothing but a declaration (if it's defined in a .o or .a file PLEASE tell me which one too, even though I know they're practically undecipherable) anyways I just want to know where the actual functions to these prototypes are at, and how I can study them or make my own "hidden" functions.

Here's a (hopefully) clear and (definitely) long explaination of how it works.

The first thing you should understand is that it's not the compiler that produces the actual executable from your code, but another program called the linker. Let's try an example.

Suppose you have a program split into three source files -- we'll call them src1.c, src2.c and src3.c. When you do the following

gcc src1.c src2.c src3.c

you are telling gcc (compiler) to make three object files (named src1.o, src2.o and src3.o) out of each C source file and call on the linker (most likely /usr/bin/ld) to actually "bind them together" into an executable called a.out.

The reason for this is that the three object files don't know about each other. If you define a function foo() in src1.c and call it from src2.c, when the latter is compiled by gcc the compiler has no clue where the heck foo() comes from -- it just knows how many arguments it takes, what their data types are, and what it returns (since you provided it with a declaration of foo() in src2.c). Fortunately, that's everything it needs in order to emit code for a function call.

This is possible because of something named the C calling convention. In short, the C calling convention is just a formal specification of how two functions interact, knowing a minimum of information about each other (precisely, the bare minimum of information that a function declaration contains). There's a lot to be said about this, but it requires some knowledge of assembly programming.

So, when the compiler is done (and is about to call the linker), we have one or more object files which call each other's functions, but aren't aware of each other's presence (e.g. src2.o is calling foo() somewhere but it doesn't know what foo()'s address in memory is because it belongs to src1.o). It is the linker's job to make the modules "aware of each other" by gluing them together and replacing function/variable names by their memory addresses in the final executable.

Now let's see what happens with strcat(). The difference here is that strcat() isn't defined anywhere in your code -- it is part of the C library. But, since it follows the C calling convention, all gcc needs to know in order to compile calls to strcat() is the number and type of the arguments it expects, and the data type it returns -- it only needs strcat()'s declaration.

When gcc is done with compiling, it will kindly ask ld to link the object file in question to the C library in your system (you don't have to tell it to do so, since all your C programs have to be linked to the C library), so that the resulting a.out is able to load it at run-time, thus making strcat() available to calls.

There's no point in looking for strcat in libc.so since it's a binary file and not meant to be read by humans. You could, however, read your libc's source code if you really want to check that strcat() is just a "normal" function like any other you could write yourself.