views:

371

answers:

5

I have some doubt about how do programs use shared library.

When I build a shared library ( with -shared -fPIC switches) I make some functions available from an external program. Usually I do a dlopen() to load the library and then dlsym() to link the said functions to some function pointers. This approach does not involve including any .h file. Is there a way to avoid doing dlopen() & dlsym() and just including the .h of the shared library?

I guess this may be how c++ programs uses code stored in system shared library. ie just including stdlib.h etc.

+4  A: 

You can link shared libraries like static one. They are then searched for when launching the program. As a matter of fact, by default -lXXX will prefer libXXX.so to libXXX.a.

AProgrammer
+2  A: 

You need to give the linker the proper instructions to link your shared library.

The shared library names are like libNAME.so, so for linking you should use -lNAME

Call it libmysharedlib.so and then link your main program as:

gcc -o myprogram myprogram.c -lmysharedlib
Arkaitz Jimenez
A: 

Then using -l switches with the name of my lib would statically link the lib?

nick2k3
No, by default it will dynamically link it (but in such a way that they will be loaded for you when your program executes - you don't have to call dlopen() and dlsym() yourself).
caf
Do I need header file for the said shared library if i use a -lXXX switch?
nick2k3
Yes, you will need the header files in order to have the declarations necessary to use the library symbols. With this method, you can use the library symbols directly, without having to use "dlsym".
Michael Aaron Safyan
A: 

If you use CMake to build your project, you can use

TARGET_LINK_LIBRARIES(targetname libraryname)

As in:

TARGET_LINK_LIBRARIES(myprogram mylibrary)

To create the library "mylibrary", you can use

ADD_LIBRARY(targetname sourceslist)

As in:

ADD_LIBRARY(mylibrary ${mylibrary_SRCS})

Additionally, this method is cross-platform (whereas simply passing flags to gcc is not).

Michael Aaron Safyan
+4  A: 

Nick, I think all the other answers are actually answering your question, which is how you link libraries, but the way you phrase your question suggests you have a misunderstanding of the difference between headers files and libraries. They are not the same. You need both, and they are not doing the same thing.

Building an executable has two main phases, compilation (which turns your source into an intermediate form, containing executable binary instructions, but is not a runnable program), and linking (which combines these intermediate files into a single running executable or library).

When you do gcc -c program.c, you are compiling, and you generate program.o. This step is where headers matter. You need to #include <stdlib.h> in program.c to (for example) use malloc and free. (Similarly you need #include <dlfcn.h> for dlopen and dlsym.) If you don't do that the compiler will complain that it doesn't know what those names are, and halt with an error. But if you do #include the header the compiler does not insert the code for the function you call into program.o. It merely inserts a reference to them. The reason is to avoid duplication of code: The code is only going to need to be accessed once by every part of your program, so if you needed further files (module1.c, module2.c and so on), even if they all used malloc you would merely end up with many references to a single copy of malloc. That single copy is present in the standard library in either it's shared or static form (libc.so or libc.a) but these are not referenced in your source, and the compiler is not aware of them.

The linker is. In the linking phase you do gcc -o program program.o. The linker will then search all libraries you pass it on the command line and find the single definition of all functions you've called which are not defined in your own code. That is what the -l does (as the others have explained): tell the linker the list of libraries you need to use. Their names often have little to do with the headers you used in the previous step. For example to get use of dlsym you need libdl.so or libdl.a, so your command-line would be gcc -o program program.o -ldl. To use malloc or most of the functions in the std*.h headers you need libc, but because that library is used by every C program it is automatically linked (as if you had done -lc).

Sorry if I'm going into a lot of detail but if you don't know the difference you will want to. It's very hard to make sense of how C compilation works if you don't.

One last thing: dlopen and dlsym are not the normal method of linking. They are used for special cases where you want to dynamically determine what behavior you want based on information that is, for whatever reason, only available at runtime. If you know what functions you want to call at compile time (true in 99% of the cases) you do not need to use the dl* functions.

quark
you wrote: "For example to get use of dlsym you need libdl.so or libdl.a, so your command-line would be gcc -o program program.o -ldl."How do I tell the linker if it has to use shared or static libraries?
nick2k3
Assuming you are using gcc? The linker will prefer the shared over the static by default. To make it prefer the static use the `-static` flag.
quark
Incidentally, when in doubt: prefer to use shared libraries. This is especially true for the system libraries. There are definitely uses for static libraries but they are usually special cases.
quark