Line 4: | Line 4: | ||
== First Scenario: Without Libraries == | == First Scenario: Without Libraries == | ||
− | + | The first scenario considers the following files, used to build the '''soup''' application: | |
+ | * '''soup.c''' - main body; uses the other components (uses '''.h''' files) | ||
+ | * '''potato.c''' - potato implementation (interface in '''potato.h''') | ||
+ | * '''carrot.c''' - potato implementation (interface in '''carrot.h''') | ||
+ | * '''tomato.c''' - potato implementation (interface in '''tomato.h''') | ||
+ | |||
+ | We assume the C language, but it could also be C++ (the idea is the same). | ||
+ | |||
+ | We assume that each vegetable is implemented as a function called by the main function. | ||
+ | Further, we assume that all the vegetables are independent from each other (and that the soup depends on each of them). | ||
=== Compiling each part === | === Compiling each part === | ||
+ | |||
+ | All parts are compiled separately, using the same command, but specific files. | ||
+ | gcc -c soup.c -o soup.o | ||
+ | gcc -c potato.c -o potato.o | ||
+ | gcc -c carrot.c -o carrot.o | ||
+ | gcc -c tomato.c -o tomato.o | ||
+ | |||
+ | Note that the '''-o''' part is optional in these commands. | ||
=== Linking and running === | === Linking and running === | ||
+ | |||
+ | Linking is carried out by the linker. In this case, we invoke it through GCC, so that we also get the C library and runtime and not just our '''.o''' files. | ||
+ | |||
+ | gcc -o soup soup.o potato.o carrot.o tomato.o | ||
+ | |||
+ | Note that each vegetable provided a function needed by the soup and that the soup had unresolved references to such functions. It is the linker's task to "connect" (resolve/link) the references. | ||
== Second Scenario: Using Static Libraries == | == Second Scenario: Using Static Libraries == |
This page provides basic examples of C/C++ compilation and linking. The objective is to provide a quick (although not complete) tour of how to organize code.
The first scenario considers the following files, used to build the soup application:
We assume the C language, but it could also be C++ (the idea is the same).
We assume that each vegetable is implemented as a function called by the main function. Further, we assume that all the vegetables are independent from each other (and that the soup depends on each of them).
All parts are compiled separately, using the same command, but specific files.
gcc -c soup.c -o soup.o gcc -c potato.c -o potato.o gcc -c carrot.c -o carrot.o gcc -c tomato.c -o tomato.o
Note that the -o part is optional in these commands.
Linking is carried out by the linker. In this case, we invoke it through GCC, so that we also get the C library and runtime and not just our .o files.
gcc -o soup soup.o potato.o carrot.o tomato.o
Note that each vegetable provided a function needed by the soup and that the soup had unresolved references to such functions. It is the linker's task to "connect" (resolve/link) the references.
Much like dynamic libraries, but each module is made into a shared object.
There is no explicit dependency between modules: symbols are used as strings.