Link with dynamic library linux

How we use dynamic linking in Linux? Give example.

Linux like Windows also supports all the linking of Windows. We shall discuss all the topics one by one briefly.

Static Linking in Linux

Static linking is the process of linking an object code directly to the executable code of the application during linking or building time of the executable. Static linking is a compilation / build time process. Let us consider mathlib.c file. We want to make it as a static library.
First we compile it with position independent flag on(-fPIC). This is needed for dynamic/static linking.

Linux library project

Linux library source

Linux library header

Linux static library

Now make a archive or static lib with the object file.
$ar rc libmath.a mathlib.o

Linux library application

1. compile the application code (place math.h in include folder)
   $cc -c libapp.c -Iinclude -o app.o
2. Link with static library math.a
   $ld app.o libmath.a -o app
3. Run the application
   $./app

Dynamic Linking

Dynamic linking is the process of linking a library function at the time of loading the application or during the runtime of the application. In contrast to static linking this happens during execution. Dynamic linking is divided into two categories — «Implicit dynamic linking» and «Explicit dynamic linking».

Implicit Dynamic Linking

Implicit dynamic linking is the process of linking a function from a shared library during the loading of the application. Let us consider once again mathlib.c file for dynamic linking. We want to make it as a dynamic library. First we compile it with position independent flag on(-fPIC). This is needed for dynamic/static linking.
$cc -fPIC -c mathlib.c

Now make a shared library with the object file.
$cc -shared libmath.so mathlib.o

1. compile the application code (place math.h in include folder)
   $cc -c libapp.c -Iinclude -o app.o
2. Link with import library math.lib
   $ld app.o -lmath -o app
3. Copy the libmath.so in lib path or current path and run the application
   $./app

Explicit Dynamic Linking

Explicit dynamic linking is the process of linking a function from a shared library during the runtime of the application using verious helper function of the dynamic loader. Let us consider once again math.c file for explicit linking. The steps for creating a shared library are same as that of implicit linking.
First we compile it with position independent flag on(-fPIC). This is needed for dynamic/static linking.

Now make a shared library with the object file.
$cc -shared libmath.so mathlib.o

• dlopen() — loads a dynamic link binary
• dlsym() — returns the function pointer if found the function entry
• dlclose() — unloads the dynamic link binary

Источник

Linking with dynamic library with dependencies

I want to compile a binary file that links with the libB. Should I link the binary with libB only or with libA either?

Is there any way to link only with the direct dependencies, letting the resolution of unresolved symbols from the dependencies for runtime?

I’m worried about the fact that the library libB implementation may change in the future, introducing other dependencies (libC, libD, libE for instance). Am I going to have problems with that?

Of course, b.cpp includes a.h and main.cpp includes b.h.

g++ -fPIC a.cpp -c g++ -shared -o libA.so a.o g++ -fPIC b.cpp -c -I. g++ -shared -o libB.so b.o -L. -lA 

Which of the bellow options should I use?

g++ main.cpp -o main -I. -L. -lB -lA 

I couldn’t use the first option. The linker complains about the unresolved symbols from the library libA. But it sound a little strange to me.

— Updated comments:

When I link the binary, the linker will try to resolve all symbols from the main and the libB. However, libB has undefined symbols from the libA. That’s why the linker complains about that.

That’s why I need to link with the libA too. However I found a way to ignore unresolved symbols from shared libraries. Looks like I should use the following command line to do that:

g++ main.cpp -o main -I. -L. -lB -Wl,-unresolved-symbols=ignore-in-shared-libs 

Looks like it is still possible to use the -rpath option. However I need to understand it a little better.

Does anyone knows any possible pitfalls when using the -Wl,-unresolved-symbols=ignore-in-shared-libs option?

— Updated comments 2:

-rpath should not be used for this purpose. It is useful to force a library to be found in a given directory. The -unresolved-symbol approach looks much better.

Here is a runnable minimal example for those looking to test this kind of stuff out: github.com/cirosantilli/cpp-cheat/tree/…

4 Answers 4

It looks like you are most of the way there already. Well done with your investigation. Let’s see if I can help clear up the ‘why’ behind it.

Here’s what the linker is doing. When you link your executable (‘main’ above) it has some symbols (functions and other things) that are unresolved. It will look down the list of libraries that follow, trying to resolve unresolved symbols. Along the way, it finds that some of the symbols are provided by libB.so, so it notes that they are now resolved by this library.

However, it also discovers that some of those symbols use other symbols that are not yet resolved in your executable, so it now needs to resolve those as well. Without linking against libA.so, your application would be incomplete. Once it links against libA.so, all symbols are resolved and linking is complete.

As you saw, the use of -unresolved-symbols-in-shared-libs , doesn’t fix the problem. It just defers it so that those symbols are resolved at run time. That’s what -rpath is for: to specify the libraries to be searched at run time. If those symbols can’t be resolved then, your app will fail to start.

It’s not an easy thing to figure out library dependencies because a symbol could be provided by more than one library and be satisfied by linking against any one of them.

Источник

C++ Dynamic Shared Library on Linux

This is a follow-up to Dynamic Shared Library compilation with g++. I’m trying to create a shared class library in C++ on Linux. I’m able to get the library to compile, and I can call some of the (non-class) functions using the tutorials that I found here and here. My problems start when I try to use the classes that are defined in the library. The second tutorial that I linked to shows how to load the symbols for creating objects of the classes defined in the library, but stops short of using those objects to get any work done. Does anyone know of a more complete tutorial for creating shared C++ class libraries that also shows how to use those classes in a separate executable? A very simple tutorial that shows object creation, use (simple getters and setters would be fine), and deletion would be fantastic. A link or a reference to some open source code that illustrates the use of a shared class library would be equally good. Although the answers from codelogic and nimrodm do work, I just wanted to add that I picked up a copy of Beginning Linux Programming since asking this question, and its first chapter has example C code and good explanations for creating and using both static and shared libraries. These examples are available through Google Book Search in an older edition of that book.

I’m not sure I understand what you mean by «using» it, once a pointer to the object is returned, you could use it like you use any other pointer to an object.

The article I linked to shows how to create a function pointer to an object factory function using dlsym. It doesn’t show the syntax for creating and using objects from the library.

You will need the header file describing the class. Why do you think you have to use «dlsym» instead of just letting the OS find and link the library at load time? Let me know if you need a simple example.

@nimrodm: What’s the alternative to using «dlsym»? I’m (supposed to be) writing 3 C++ programs that will all use the classes defined in the shared library. I also have 1 Perl script that will use it, but that’s a whole other problem for next week.

Источник