Let me try to explain the compilation process which may help you
to understand where your problem lies.
* Build system
* Maintain program/library dependencies
* Execute commands resulting in a usable program/library
* Compiler
* Lexical Analysis
* Parsing
* Language translation
* Optimizations
* Linker
* Combine machine code from multiple locations
* Optimizations
Each stage is feeding into the next and interacting with one may
not require explicit interaction for the next.
=== Linker
The linker is at the bottom of our list because it will be the
final step in creating an executable/library. There is not one
single linker, there are many for different operating systems and
programming languages. The 'ld' linker is common on Linux,
Windows has a linker called link, and DMD makes use of optlink
for its 32-bit build.
At the time the linker is called the source code has already been
translated into machine code by the compiler. So the linker has a
simple task of packaging up the machine code which makes up your
program. This means locating the machine code for libraries being
used and combining it with the instructions you've specified. One
of the most common errors you'll receive from a linker is that it
can't find the corresponding machine code.
Consider yourself the linker and, as the compiler, I will request
that you do some work for me. The programmer has asked me to
compile decentApp.d for them and makes a call to spiral(). If I
give you the machine code for decentApp could you please include
the machine code for famous.awesome.spiral() too? Are you able to
locate machine code for famous.awesome.spiral?
The answer is that you can't, not with out being told where to
look, what to look for, or searching every location for any
machine code matching that symbol (when you make function calls
the linker doesn't care it is a function, it considers it a
symbol or reference for some chunk of machine code).
The solution, tell the linker where it will find the code, it is
just a polite thing to do.
Once the linker has all the code it can perform optimizations,
one of the most common is throwing out code which isn't being
used.
=== Compiler
The compiler is a translation tool, making conversion from one
language to another.
When it translates a chunk of code, there can be references to
other chunks some of which may have already been compiled, and
some that may still need compiled. What is important to the
compiler is making sure that the call out to that chuck of code
is formed in the agreed upon structure. It does this by examining
the function signature, in C/C++ we see this information provided
through a header file.
Since the compiler doesn't have to build every chunk of code that
the program is being run, as long as it has the function
signature it can translate code that call into some unknown
location. And this is where the -I flag comes in play. When you
provide the -I with a location, it signals to the compiler that
it should look for the function signatures of this code chunk in
the locations specified.
However, the compiler does not build the code that it finds, it
expects you have already done that because you're not telling it
to build that code. It will then pass off the translated code to
the linker and request an executable be built.
The linker however only knows about the code the compiler has
told it about (and some default search locations). If it can find
it in the code provided by the compiler, or the places it was
told to search then it will fail.
This is where the -l linker flag comes in (assuming Linux), when
passed on the compiler it would be -L-l (pass to the linker the
flag -l). Using -l specifies what libraries to find reference
code in, and -L is used to specify what directories to look in
for the requested library.
When you tell the compiler to build your code and it will find
some of the code over here in -Ifoo it is probably wrong if you
don't also include a -L-l and possibly -L-L in that same command.
Most likely you want a build system that handles dependencies for
you, check out DUB.
