CODEWITHSUNDEEP
c++linkercmake
Tibor Takács
Tibor Takács

Reputation: 4808

Linking a shared object into other shared object C++ project

I am working in a very big C++ project to create a big shared object where we are using an external SDK which have several header files and several shared libraries which belong to each other. This means that the declaration of SDK classes are in the header files but their definitions are in the shared objects.

I understand that because of the declarations in header files I can compile this code.

But what I do not understand exactly is when do I have to specify the used shared objects for the linker explicitly?

Namely if I specify it (e.g. in cmake with target_link_libraries command) then the linker can check that a symbol will be in the shared library or not. But what happens if I do not specify it (i.e. there is not any -l[shared_object_name] flags in linkage)? My experience is (which surprised me) that is work properly (i.e. the whole building process finished). How can it possible?

Upvotes: 0

Views: 313

Answers (2)

rodrigo
rodrigo

Reputation: 98358

In POSIX shared libraries, you can have undefined symbols in a shared library, and all will link just fine. As long as the executable is fully linked, there will be no linker errors.

That's done this way because dynamic libraries mimic the behaviour of static libraries, and static libraries can have undefined symbols (static libraries are not linked, to begin with).

If you come from a Windows background, then it will surprise you, because Windows DLLs cannot have undefined symbols.

If you are worried about this, you can check the linker options --no-undefined and --no-allow-shlib-undefined.

Upvotes: 3

Lightness Races in Orbit
Lightness Races in Orbit

Reputation: 385144

My experience is (which surprised me) that is work properly (i.e. the whole building process finished).

That seems unlikely.

In fact…

How can it possible?

It's not.

The only explanation is that you weren't using symbols defined inside those library files. They were either in header-only parts of the third-party code, or they weren't part of the third-party code at all.

Or you were building a shared library of your own. The ultimate executable would still need the third-party libraries linked in, though.

Upvotes: 2

Related Questions