GCC / Linux: adding a static library to .so?

I have a program that implements a plug-in system, dynamically loading a function from some plugin_name.so (as usual).

But in turn, I have a static "helper" library (let's call it helper.a), whose functions are used both from the main program and from the main function in the plugin. They should not interact in any way, they are just helper functions for processing text, etc.

This program, after its launch, cannot be restarted or restarted, therefore I expect the availability of new "auxiliary" functions from the plugin, and not from the main program.

So, my quest ... is it possible to force this “plug-in function code” in .so to use (statically link against?) A different (possibly newer) version of the “helper” than the main program?

How can I do that? perhaps by static binding or otherwise adding helper.a to plugin_name.so?

+6
c ++ gcc linux linker
source share
3 answers

Nick Meyer's answer is correct for Windows and AIX, but is unlikely to be correct on all other UNIX platforms by default.

On most UNIX platforms, the runtime loader supports a single namespace for all characters, so if you define foo_helper in a.out as well as plugin.so and then call foo_helper from one, the first definition is visible to the runtime loader (usually this from a.out ), used by default for both calls.

In addition, the image is complicated by the fact that foo_helper cannot be exported from a.out (and therefore may not be visible to the loader at runtime) unless you use the -rdynamic flag or some other links to the This shared library. In other words, it might seem like everything works as Nick described them, then you add a shared library to the a.out link line and they no longer work like that.

On ELF platforms (like Linux) you have great control over visibility and character binding. See the Description of -fvisibility=hidden and -rdynamic in the GCC manual page, and -Bsymbolic on the link builder page.

Most other UNIX platforms have some way of managing character bindings, but this is necessarily platform dependent.

+6
source share

If your main program and dynamic library are statically referencing helper.a, you don’t have to worry about mixing versions of helper.a (unless you do things like pointers to passages highlighted in the .a helper between .exe and .so borders) .

The code required from helper.a is inserted into the actual binary when you reference it. Therefore, when you call helper.a from .exe, you will execute the code from the code segment of the executable image, and when you call helper.a from .so, you will execute the code from the part of the address space into which .so was loaded. Even if you call the same function inside helper.a, you call two different “instances” of this function, depending on whether the call was made from .exe or .so.

+1
source share

I think this question is the same as yours. How do I get characters from a static library to be included in a shared library assembly?

The -whole-archive linker option should do this. Would you use it for example

gcc -o libmyshared.so foo.o -lanothersharedlib -Wl, - whole-archive -lmystaticlib

and it works for me.

0
source share

All Articles