4

I wanted to see what happens if I include the source file instead of the header file.

main.c

#include <stdio.h>
#include "func.c"

int main(void)
{
    printf("%d\n", call());
    return 0;
}

func.c

int call(void)
{
    return 100;
}

compilation command

cc main.c func.c -o program && ./program

error

/usr/bin/ld: /tmp/ccZZ43AI.o: in function `call':
func.c:(.text+0x0): multiple definition of `call'; /tmp/ccXvHf37.o:main.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

But when I change the function definition from int call(void) to static int call(void) it compiles and works. Why when defining the function with static it compiles?

Improve this question
5
  • 6
    If you have #include func.c then you should not have it in cc main.c func.c -o program. Commented Jan 7 at 12:19
  • C is not particularly conducive to learning by experiment (I can't name a programming language that is). But if you persist with such experiments, or for other cases where you encounter behavior you do not understand, you would do well to have some kind of non-interactive reference available to consult. Even just typing "what does static mean in C?" into your favorite search engine would have gotten you something to go on in seconds. Possibly even a reference to SO's own What does "static" mean in C?. Commented Jan 7 at 13:14
  • This is the perfect time to learn about the concept of translation units. Basically a translation unit is a single source file all included header files. Now think about what will be inside the main.c translation unit when you build it, considering that #include is a literal inclusion of files. Commented Jan 7 at 14:01
  • This question is similar to: Including one C source file in another?. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem. Commented Jan 7 at 14:50
  • The extension you choose shows your intent. A file named with a .c extension is intended to be separately compiled, while a file with a .h extension is intended to be included. Otherwise there is no difference, they are just text files. You could use #include "func.xyz", the compiler doesn't care. We poor humans do care, so it is better to follow the convention. Commented Jan 7 at 14:54

3 Answers 3

Reset to default
6

Whenever we add a .c file to the list of files to compile, the compiler works with something called translation units which contains that .c file and all the headers that the file includes. This will then get compiled into an object file of some kind (.o in this case) that is then passed on to the linker.

In this case since you typed cc main.c func.c, you will have two such translation units originating from main.c and func.c both. These contain functions that have external linkage, meaning that the compiler/linker will have to expect that function to get called from elsewhere. Because of that, each resulting object file will contain a function call, which may be called from any other source file. This results in a conflict because of that, detected at the linker stage.

If you make it static then the function gets internal linkage, meaning that each translation unit still ends up with a local copy of the function but it is not exposed to other parts of the program. Where one of the functions (the one in func.c) is never called and therefore removed by link-time optimizations.

The easy fix would be to not include func.c in the compilation, since the contents of that file will get included from main anyway.

The correct fix however, is to follow best practices:

  • Never include anything but header (.h) files.
  • Every .c file shall have its corresponding header file with the same name, which it includes.
  • Every header file should have "header guards" (#ifndef MYHEADER_H #define MYHEADER_H ... #endif.)
  • Every public function in the .c file which should be used by other parts of the program should have a function declaration in the header file (along with the documentation of how to use it).
  • Every private function in the .c file not to be used by other parts of the program should be declared static and without a function declaration in the header. (It may still have a function declaration at the top of the .c file though.)
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

6

There are 2 issues here:

  1. Wrong #include:

    You #include a c file. This should [almost] never be done.
    Instead create a header file like func.h with a declaration for the function:

    int call(void);

    And #include this header in every c file that uses call().
    At the moment with your #include "func.c", the linker encounters 2 definitions for call(): one in the translation unit of main.c and one in the translation unit of func.c.
    This is invalid - global symbols must generally be defined once.

  2. Making the function static:

    static in this context means that the function is limited to the current translation unit (i.e. it has internal linkage).
    Therefore each translation unit has "its own" call() function and the linker does not expect it to be unique and available globally (like it would expect for functions with external linkage).
    But as explained above this only hides the issue of the wrong #include explained above.

Improve this answer

2 Comments

All scopes are limited to the translation unit or less. C has no greater scope. The issue is linkage, not scope.
I removed the mention of scope. However I am still not sure I used the exact proper terminology. Please fell free to rephrase.
5

The name of an object of function is called its identifier.

A translation unit is one source file being compiled as it appears after each #include directive in it is replaced with the contents of the included file.

In C, an identifier used in one place can refer to an identifier defined in a different place through a process called linkage.

When an object or function is declared at file scope (outside of any function), it has external linkage by default. With external linkage, an identifier used in one translation unit can refer to an identifier defined in another translation unit.

When you execute cc main.c func.c -o program, the command compiles main.c as one translation unit and separately compiles func.c as another translation unit. These compilations produce two temporary object files, and the command links those object files together.

When main.c has #include "func.c", the definition of call is included in main.c and is part of that translation unit. So this translation unit has a definition of call with external linkage.

You also compile func.c, and this translation unit also has a definition of call with external linkage.

When there are two definitions of the same identifier with external linkage, the C standard does not define the behavior. Most commonly, when there are two ordinary definitions of a symbol in object files, the linker reports an error.

When you define call with static int call(void), that changes its linkage to internal linkage. Internal linkage limits resolution of an identifier to the translation unit it is declared in. Then the use of call in main is resolved to the call that is defined in main.c, and the call that is defined in func.c is not involved and does not cause any conflict.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.