CODEWITHSUNDEEP
c++clinuxlinkerg++
Mark Rollins
Mark Rollins

Reputation: 39

Removing linker dependencies

I'm working on a c++ app on linux using g++. My app links in a shared library that exposes a simple API I need. This library internally references a large number of additional shared libs. I've had to find each and every one and add them to my Makefile to get them linked in.

I assume my app has to link to any of the libs the primary lib depends on. Is the only way around this linking requirement, having the primary lib compile in the static libs of all its dependencies? Does this apply to using the plug-in model via dlopen/dlsym?

ty

Upvotes: 1

Views: 2166

Answers (3)

nos
nos

Reputation: 229224

Is the only way around this linking requirement, having the primary lib compile in the static libs of all its dependencies?

No. The shared library could itself link to the shared libraries it depends on. Most linkers would pick up those libraries as well, and link your executable to those libraries without you mentioning them at the linker stage.

In your case, it sounds like the shared library did not link to the libraries it required. the ldd tool can be useful in this regard.

As an example, say you produce this shared library:

gcc -shared foo.o -o libfoo.so -lm

Now the libfoo.so is linked to the math library (libm). Any application linked to libfoo.so would be linked to libm as well, i.e. you'd just have to do

gcc -o prog main.o -lfoo

If on the other hand the shared library was not linked to lib, but was produced with only

 gcc -shared foo.o  -o libfoo.so

You'd have to explicitly link to libm when linking your application:

gcc -o prog main.o -lfoo -lm

When you dlopen() a shared library, the runtime linker will load all the libraries that shared library was also linked against - unless they're already loaded. So - if a library you dlopen() is not linked against libraries it depends on, and your executable are not linked against those libraries either, dlopen() will fail (unless you specify RTLD_LAZY, in which case things fail later on)

Upvotes: 4

Jonathan Wakely
Jonathan Wakely

Reputation: 171383

I assume my app has to link to any of the libs the primary lib depends on.

It sounds as though either your app is using those symbols directly (not just indirectly through the API shared lib) or that shared lib hasn't been linked properly, so it wasn't linked to the libraries it depends on. If when that shared library was created its dependencies were linked to with -l then it would cause them to be linked to automatically when linking your app to the API lib.

Is the only way around this linking requirement, having the primary lib compile in the static libs of all its dependencies?

That's one way, but not the only way.

Does this apply to using the plug-in model via dlopen/dlsym?

As long as the plugins are correctly linked to the libs they depend on ... No, in that case the linker cannot possibly know what libs you will dlopen at run-time, so can't know what their dependencies will be, so you don't need to name them at link-time. It wouldn't be possible to without knowing in advance all the plugins that might get loaded.

If the plugin libraries weren't properly linked you'd get the same problem when trying to dlopen them.

Upvotes: 1

BЈовић
BЈовић

Reputation: 64263

I assume my app has to link to any of the libs the primary lib depends on. Is the only way around this linking requirement, having the primary lib compile in the static libs of all its dependencies?

Off course. There are no ways around : either static linking, or having libraries (correct versions, if not ABI compatible) in libraries run-time search path.

Does this apply to using the plug-in model via dlopen/dlsym?

No. For that, you need to have shared library in a path from which you want to load it.

Upvotes: -1

Related Questions