Question

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.

Answer 1

There are two questions here:

1. Why does test.c compile without a header providing declarations of routines in the library?
2. Why does the link work with 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.