0

I went through the How to load a dynamic library on demand from a C++ function/Qt method

It seems if we have to load a shared library on run time . We always write code to resolve the function/symbols names in shared objects using

1) dlsym , if we load the shared library on run time using dlopen .Or

2) Other techniques as proposed in How to load a dynamic library on demand from a C++ function/Qt method

3) Since my shared library will have millions of symbols/functions for example my shared library has functions

fun1() , fun2 ..... fun1000000

is there any direct way where we do no need write any code to resolve the function/symbols names and just call the functions from shared library functions directly after loading the shared library.

The algorithm I am looking for 

void loadSharedObject() {  
    //load the
    // Call the function names directly
    // no extra code for resolving the function /symbols names   
    // for example  
     fun1()
     fun2()
 }
Community
  • 1
  • 1
TechEnthusiast
  • 273
  • 4
  • 18
  • If your library embed a `QObject`, you can use its Meta object mecanism to get and call its functions. Otherwise, you have to parse the ELF structure (readelf on Linux) and use dlsym (it could be tricky). – Dimitry Ernot Sep 04 '16 at 15:28
  • Why do you care about any of it? What problem are you trying to solve? Doesn't it ring any bells to you that you seem to be fighting an uphill battle that nobody else seemingly is fighting? You're trying too hard. And it's unnecessary. – Kuba hasn't forgotten Monica Sep 15 '16 at 13:36

1 Answers1

0

If you make the symbols callable directly like that, you're just doing ordinary linking. That's what ordinary linking makes possible. With dynamic loading of a library, you're getting the ability to discover symbols after the linking stage — occasionally very useful — but at a cost of the program doing the loading not being able to directly talk about the symbols. Instead, you have to do dlopen() and dlsym() to open a library and get references to the symbols in it, but then the references are just raw pointers; you have to apply the right cast to convert them into function pointers with the right signature, and then you can call them through the function pointer.

(Windows uses a different API — LoadLibraryEx() and GetProcAddress() — but the general things they do is equivalent.)

You can save the symbol references in local or file-local variables. That works, and then you can pretend that the symbols as you have named them locally are callable just any other function. You probably want to use a typedef to define the type signature of the function; function types are a bit ugly in C and C++.

The code below lacks error handling and in particular, you must check whether dlopen() and dlsym() worked or you'll get a hard crash if something fails.

typedef int (thefunc_t)(int x, int y);

void *handle = dlopen(libraryname, RTLD_LOCAL);
void *sym = dlsym(handle, "thefunc");
thefunc_t *thefunc = reinterpret_cast<thefunc_t *>(sym);

// Now, assuming everything worked, you can just call it like this:
int z = thefunc(1, 2);
Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • Yes, you can make an array of them. It's not hard. However, the code that you are loading needs to use the `extern "C"` conventions because de-mangling C++ function names is tricky at best (and not very portable either). – Donal Fellows Sep 04 '16 at 22:31
  • When we link the a shared library and run the executable how does the symbols of shared libraries are resolved and what are the system calls to resolve the symbols of shared libraries . Also it will be helpful if you could point me a documentation how does linker are loader works . How does symbols are resolved when a linker a shared library – TechEnthusiast Sep 05 '16 at 10:56