Ha, this sounds more complicated, than it actually is. Here's what I mean:
Suppose I write an application, that uses threads. In this application, I don't use the pthreads
directly, but I use a wrapper, that uses pthreads
. So, in this wrapper's makefile, -lpthread
must be included. And the question - do I need to include -lpthread
in my project, or it's not necessary? Or it depends? If so, on what?
I'm asking this, because I've seen this a lot and I don't think it's necessary.. The same for -std=c++0x
?
Also, I had a problem with the Informix C++ interface, as it relies on lib, called DMI
, which is built on the top of ESQL/C
. When I removed these libraries and use only the real one, I got linker problems(problems with finding the libs). When I added dmi
and esql/c
, everything was fine.
Does this answers my question (with "YES"), or I could've done something wrong, other than this (I'm newbie with makefiles (: )
source: "Makefiles are something of an arcane topic--one joke goes that there is only one makefile in the world and that all other makefiles are merely extensions of it. I assure you, however, that this is not true; I have written my own makefiles from time to time."
This made me think if all included libraries in the makefiles (of my company's projects) are necessary, or this is for "historical reasons"
EDIT: The wrapper around pthread
is linked static, and the Informix
lib was dynamically linked, if this matters.
Also, the OS is RHEL (4 and 5), but I need to know if this depends on the OS and on the way of linking (dynamic or static)
This is where you do a mistake:
So, in this wrapper's makefile,
-lpthread must be included
A static library created by the ar
tool is just a collection of object files in a special file format that is recognised later by the linker. This collection of code isn't linked to any library. Specifying -lpthread
when compiling each of the source files at this stage is pointless because no linking is done.
Only when calling the linker to produce the final executable out of all libraries and object files, you need to pass the particular libraries with the -l
option. Note that the compiler is not invoked at this step, and -l
is not a compiler option, but a linker option.
For example, this only invokes the linker because no source files are supplied:
gcc -o myprog main.o -lmylib -lpthread
By contrast, compiling a source file to an object file and specifying a library is pointless because no linking is going to be performed:
gcc -c wrapper_source.c -lpthread
Unless the libraries are somehow included in the wrapper you are using, the answer is YES you will need to include them in the makefile of the program that uses the wrapper.
For instance if the wrapper is a .o, it hasn't been linked to anything yet. However, if the wrapper is a .so or .a, it may include the libraries depending on how you constructed it. I think ar is responsible for this kind of things.
All dynamically linked libraries must be present.
Usually, when your application uses a wrapper in a shared library, is not aware of the wrapper's makefile and cannot find out that it needs to include pthread. On the other hand, the linker working on your application usually does want to make sure there are no undefined symbols left in the project.
Therefore you will have to add directives for all shared libraries your code depends on.