Reputation: 618
I have a function in libA.so
that is used in libB.so
,
And a function in libB.so
that is used in libA.so
!
So defenetly i can not compile none of these libraries.
How can I compile these two libraries?
Should i used third library and move the dependebcies to this library?
I used qt and c++
Updated: in compile libA.so get error cannot find libB.so and in libB.so get error can not find libA.so
Upvotes: 1
Views: 2742
Reputation: 1
I have a function in libA.so that is used in libB.so, And a function in libB.so that is used in libA.so!
This is wrong design. A library cannot, even indirectly, depend upon itself. Such a circularity is the symptom of something very wrong, and you are misunderstanding what a software library is (it is more than a random collection of functions, or of object files; it has to be somehow a "software module" and it is related to modular programming and often defines and implements completely a collection of related abstract data types).
So throw both libA.so
and libB.so
away. And make a single libAB.so
containing all the code that you have put in both libA.so
and libB.so
shared objects (and not genuine libraries).
The answer from n.m. gives a technical way to solve your problem, but at heart your design is wrong and you are abusing libraries (and you cannot call your libA
or your libB
a library, even if you built them as some shared object in ELF).
You could also design your code by adding some indirection with callbacks, or closures or function pointers held in some variable or data (and provide some way to set these callbacks, or initialize the closures or the function pointers at runtime). Since you use Qt, consider also defining appropriately your new Qt signals and slots (they are based on some callback machinery).
Read Program Library HowTo and Drepper's How to Write Shared libraries paper for more.
Upvotes: 0
Reputation: 618
Finally I solve it.
As @n.m. said we dont need to link libA.so and libB.so in compile time, so I remove -lA
and -lB
when build them and i didnt get any error. And In app that want to use libA.so or libB.so I linked them with -lA
or -lB
. So this work correctly.
Upvotes: -1
Reputation: 119877
BIG FAT DISCLAIMER Only do this if absolutely necessary. The preferred way is to refactor your project structure such that it doesn't contain dependency cycles.
When producing a shared library, the linker in general does not need to know about other shared libraries. One can use them on the command line but this is optional. Example:
// libA.cpp
extern void funcB();
void funcA() {
funcB();
}
Compile and link:
g++ -fPIC -c libA.cpp
g++ -shared -o libA.so libA.o
funcB
is supposed to live in libB.so
but we are not telling the linker where to find it. The symbol is simply left undefined in libA.so
, and will be (hopefully) resolved at load time.
// libB.cpp
extern void funcA();
void funcB() {
funcA();
}
Compile and link, now using libA.so explicitly (ignore the infinite recursion, it's just an example):
g++ -fPIC -c libB.cpp
g++ -shared -o libB.so libB.o -L/where/libA/is -lA
Now it is up to the executable to load libB.so
before loading libA.so
, otherwise libA.so
cannot be loaded. It's easy to do so (just link the executable with only libB.so
and not libA.so
), but can be inconvenient at times. So one can re-link libA.so
after building libB.so
:
g++ -shared -o libA.so libA.o -L /where/libB/is -lB
Now one can link an executable to libA or libB and the other one will be picked up automatically.
Upvotes: 2
Reputation: 274
This seems a bit problematic for future re-use, you might want to either separate your functions differnetly between those libraries or create a third one thatt contains all of the "tool" funtions to have LibA
and libB
function without one another .
Upvotes: 1