C ++ Linker Question - Dynamic and static library dependency

I have a library X that depends on a library Y. I have an application A that calls functions from X.

Let's assume library Y is only available as a static library. If both X and Y are statically linked to App A, everything works fine. However, I want X to be a dynamic (shared) library.

Currently, when Y link statically does not work as dynamic X cannot see what is in Y.

Is there a way to get Y as a dynamic library without statically linking X to Y? It is not okay for us to wrap Y so that we have a dynamic version of Y. Generally speaking, are there any linkers available that somehow map Y (which is statically linked to A) to X (dynamic link library)?

The reason I am asking is because I also have a Z library that also depends on Y. I don't want to statically link Y to X and Z so that X and Z can be dynamic.

Hope this is not too confusing. I appreciate any help.

+2


source to share


3 answers


You want to compile a dynamic version of X that statically links Y. Then the application only links X and ignores the use of Y. Whether or not you can do this is platform dependent, I think - I know GCC and GNU will do it. linker. The problem is that the code compiled for use as a static library and the code compiled for use as a dynamic library are not identical; dynamic libraries are generated in such a way that they can be moved to any memory location (this makes them accessible). On Linux and Solaris, this means that shared libraries are compiled with the "-fpic" directive. If you mix PIC'd and non-PIC'd code when you make your shared library (this happens when you statically link Y to X),you will get errors regarding unresolved text movements - that the linker complains that parts of your library cannot be changed. You can turn off warnings by passing -mimpure-text. However, understand that any page in memory that contains code that has not been compiled with "-fpic" (so that any page that calls Y) will not be used across applications. Therefore, if multiple applications are using your library, they will not get the full memory savings typically provided by shared libraries. There are probably equivalent flags for MSVC on Windows if your platform is.that any page in memory containing code that has not been compiled with "-fpic" (so that any page that calls Y) will not be used across applications. Therefore, if multiple applications are using your library, they will not get the full memory savings usually provided by shared libraries. There are probably equivalent flags for MSVC on Windows if your platform is.that any page in memory containing code that has not been compiled with "-fpic" (so that any page that calls Y) will not be used across applications. Therefore, if multiple applications are using your library, they will not get the full memory savings usually provided by shared libraries. There are probably equivalent flags for MSVC on Windows if your platform is.



Edit: On my first reading, you didn't notice your Z problem. Try compiling X and Z with "-z undefs" so that GCC will ignore undefined characters, and then when you link your application, make sure Y is included in the linkline after X and Z (later libraries fill in links found in earlier libraries).

+3


source


Well, it's pretty easy to convert the static library to .so:

gcc -shared library.a -oliblibrary.so



Does this solve it?

+1


source


As you point out - if you wrapped Y or had dynamic Y your problems would be solved.

Why can't you wrap Y to make it dynamic?

Why can't you get dynamic Y?

Given your implacable constraints, you may need to link Y for Z and X. You basically delete all of your options ...

0


source







All Articles