Reputation: 435
I'm new in C and especially writing static libraries and I'm getting strange behavior from my library.
I wrote a little static library called cde. I compiled the different parts with gcc into .o-files and then I used ar to put them all together into an .a-file
Now, when I want to test my library I do the following:
gcc test.c -L../bin -lcde -lelf
libcde.a is my library located in ../bin. libelf.a is a library I need for my library (i don't know how to put it directly into my own library...).
The thing is that I can call every function of my library without having to include the header-file of my library. How is that possible? At compile-time the files shouldn't be linked so the compiler should have no idea what functions are available inside my library...
When I run it the following way,
gcc -L../bin -lcde -lelf test.c
the file test.c can't find any of my functions defined in my header file even though I've included it.
I think I'm doing something fundamentally wrong here, but I really can't find out what.
Upvotes: 1
Views: 3726
Reputation: 224032
There are two questions here:
test.c
compile without a header providing declarations of routines in the library? test.c
listed first on the command line but not with test.c
listed last on the command line?We cannot provide a full answer to the first because you have not shown the source code. As others have indicated, C has some leeway to provide implicit declarations, largely for historical reasons. Those implicit declarations might not match the actual definitions of your routines, which can cause errors, so you should avoid implicit declarations.
The answer to your second question is this. Given either of the two command lines you show, the compiler compiles test.c
and then invokes the linker. (The compiler can also be made to do other things, such as to compile without linking or to link object modules from previously compiled sources.) When the compiler invokes the linker, it passes the linker arguments in an order that corresponds to the order you passed them to the linker. In particular, if you put -lcde
before test.c
, then the compiler puts -lcde
before the object module that comes from test.c
, test.o
, when it runs the linker.
This is important because of the way the linker operates. Among other things, the linker has a list of symbols that it needs definitions for. The list is initially empty. The linker processes inputs from the command line from left to right. When the linker sees an object module like test.o
in its command line, it reads the object module and processes it. Often, an object module contains references to some symbols that it does not define, such as calls to library routines. If the linker already has definitions of these symbols from a previous file, it connects the references to the definitions. If it does not have definitions, it adds the symbols to the list of symbols the linker needs definitions for.
When the linker processes a library file, it checks each object module within the library to see if that object module defines a symbol that is on the linker’s list of needed definitions. If so, the linker reads that object module and adds it (and its definitions) to the executable the linker is building. If not, the linker ignores that object module.
Now we can see why test.c -lcde
works but -lcde test.c
does not. In the former case, the linker makes a list of everything that test.o
needs, then it gets those things from the cde
library. In the latter case, the linker sees the cde
library but does not need anything from it yet, so it goes on without taking anything from the library. Then the linker reads test.c
and adds to the list of needed symbols. Then the command line ends, and the linker has no more files but still has symbols without definitions. So it reports an error.
So, generally, libraries should be listed last on command lines.
Upvotes: 9
Reputation: 3459
In C, a function called without a prototype is assumed to have its prototype like this:
int function();
Which means a function accepting any number of any arguments, returning an int. So, of course it works, but try passing an argument your functions in libcde do not expect and it will crash.
You can put libelf.a in your library (rather, copy the object files from it into yours), it is just seldom a good idea: you become dependent on the local system configuration (you'll have to find where the library is located).
Upvotes: 1
Reputation: 229284
Without header files, you will not have the prototypes for your functions. This is not an error, however a C compiler will assume the prototype of a function you call, for which the compiler has not seen a prototype to be
int functionname()
The empty () means something like "any arguments", so any argument you pass to that function, that's the way the function will be called.
Depending on the actual types of the arguments, and the return value of your function, that might work out just right, or it might at least appear to work in some situations.
At the linking stage, when you produce the executable, the linker will just link in the name of a function. If you call a function named "foo" , and your library also have a function symbol named "foo", that's what the linker picks.
Upvotes: 5
Reputation: 33272
The headers in C++ are used also to provide the prototypes for the function you want to call. Prototypes are used by the compiler to help you don't mistake the parameter count/type when you are calling an external function. So by this point of you static or dynamic library does not make any difference.
Upvotes: 0