I am on OS X, and I have a .so file which I want to link to a .o file during execution. For example Foo.so should be linked to Bar.o during while calling ./Bar.o . I am using the Terminal application to run my app and I compiled my project using a Makefile.
Asked
Active
Viewed 923 times
0
-
Usually you just compile with the -l flag, e.g. `g++ Bar.cpp -l Foo.so -o Bar.o`. Does this not work? Why do you need Foo.so to be linked? If you can post your Makefile that would be helpful ... – maditya Jul 20 '13 at 01:17
-
I have been suggested this approach. The thing is, my Makefile has been generated using cmake and the project is very large. I am unable to find the exact spot where the linking takes place as per my current knowledge of Makefiles and cmake. – shaveenk Jul 20 '13 at 01:26
-
is there no way to link at runtime? – shaveenk Jul 20 '13 at 01:37
-
Sorry, I misunderstood your question. I think it's possible but unfortunately I don't know how ... Also, what error do you get with cmake? Have you already tried changing your LD_LIBRARY_PATH variable to include Foo.so? – maditya Jul 20 '13 at 02:00
-
Finally got it to work. But that was by linking during compile time. But I still really want to know if it is possible to link it during execution. I know that there are two types of dynamic libraries. Those which are statically present during compilation so that the compiler is aware that the files exist and the second type is the one where the compiler does not know about its existence. I haven't tried the LD_LIBRARY_PATH to set the path of the dynamic libraries still. I will do so next. That might be the answer. – shaveenk Jul 20 '13 at 03:30
-
Well looks like setting the LD_LIBRARY_PATH or even using -L during linking to set the library directory does not suffice. The actual library has to still be linked at compile time even if it is a dynamic library. Still trying to find out if there is a way to link at execution time. – shaveenk Jul 20 '13 at 23:52
-
Now I'm curious about it as well. I'm sure _someone_ on SO knows about whether or not it's possible. Maybe if you provide more detail in your question, it'll get more attention and catch the eye of the right person to answer it ... Good luck! – maditya Jul 21 '13 at 00:37
-
@shaveenk There are some subtleties to what dynamic linking requires at link time and at run time. At link time, the symbols in the lib must be defined. At run time, there must be a shared lib with the name and path of the original lib that defines the symbols that get used. The executable "won't notice" if you make changes. This is how system libs can be updated without forcing everything that uses them to be updated. – Praxeolitic Jun 13 '14 at 18:56
1 Answers
1
On Unix and OS X you can do this with libdl.
The basic idea is that you compile and link an executable. At some possibly different point in time and place, someone who might not be you compiles and links a shared libray. If at runtime the executable can get strings for the the shared library filename and the symbol of a function that you want to load, then you can use libdl to get a void* to that contains the address of a function in the shared lib. The appropriate function pointer type must be known to the executable at compile time because the next step is to cast the void* to whatever type was "secretly prearranged" between the executable and the dynamically loaded lib. After casting you're good to go.
This tutorial shows the traditional approach for dynamically loading functions. Classes requires some indirection via factory functions.
http://www.tldp.org/HOWTO/html_single/C++-dlopen/
The approach above is where to start but it has the drawback that all communication between the executable and lib must be through C style function signatures created with extern "C" before functions (most significantly no templates or overloads). This is just a limitation on the ports of communication between the executable and lib. Both can use C++ internally. If you want to dynamically import overloaded functions here's a way.
Dynamic Loading Without extern "C"
You have to be careful with user defined classes. The binary representation of classes is not standardized in C++. If a custom class passes from executable to lib but the executable and lib have different ideas of which bits mean what, you won't get the behavior you wanted.
Also, if you compiled your shared library on OS X, you have a dylib, not an so. They're slightly different.
Community
- 1
- 1
Praxeolitic
- 22,455
- 16
- 75
- 126