28

I am building a Java application that uses a shared library written in C++ and compiled for different operating systems. The problem is, that this shared library itself depends on an additional library it normally finds under the appropriate environment variable (PATH, LIBRARY_PATH or LD_LIBRARY_PATH).

I can - but don't want to - set these environment variables. I'd rather load the needed shared libraries from a given path at runtime - just like a plugin. And no - I don't want any starter application that starts a new process with a new environment. Does anybody know how to achieve this?

I know that this must be possible, as one of the libraries I use is capable of loading its plugins from a given path. Of course I'd prefer platform independent code, but if this ain't possible, seperate solutions for Windows, Linux and MacOS would also do it.

EDIT I should have mentioned that the shared library I'd wish to use is object oriented, which means that a binding of single functions won't do it.

aRestless
  • 1,825
  • 2
  • 18
  • 27

4 Answers4

42

Un UNIX/Linux systems you can use dlopen. The issue then is you have to fetch all symbols you need via dlsym

Simple example:

typedef int (*some_func)(char *param);

void *myso = dlopen("/path/to/my.so", RTLD_NOW);
some_func *func = dlsym(myso, "function_name_to_fetch");
func("foo");
dlclose(myso);

Will load the .so and execute function_name_to_fetch() from in there. See the man page dlopen(1) for more.

johannes
  • 15,807
  • 3
  • 44
  • 57
  • I think i should have added that the shared library itself is object oriented. If only functions can be "linked", this won't work, right? – aRestless Oct 05 '11 at 10:38
  • If you know the name the linker generates you can access any symbol. A good practice is having a function using C calling conventions which returns a pointer to a structure which contains objects or something. – johannes Oct 05 '11 at 21:25
  • Well, I already do that - to access the library via Java. The C++ library I'm writing is nothing but a stub using the third party library (which I am not able to alter). – aRestless Oct 05 '11 at 22:12
16

On Windows, you can use LoadLibrary, and on Linux, dlopen. The APIs are extremely similar and can load a so/dll directly by providing the full path. That works if it is a run-time dependency (after loading, you "link" by calling GetProcAddress/dlsym.)

Anteru
  • 19,042
  • 12
  • 77
  • 121
7

I concur with the other posters about the use of dlopen and LoadLibrary. The libltdl gives you a platform-independent interface to these functions.

Michael Malone
  • 618
  • 6
  • 18
thiton
  • 35,651
  • 4
  • 70
  • 100
-1

I do not think you can do it for it.

Most Dlls have some sort of init() function that must be called after it have been loaded, and sometime that init() function needs some parameters and returns some handle to be used to call the dll's functions. Do you know the definition of the additional library?

Then, the first library can not simply look if the DLL X is in RAM only by using its name. The one it needs can be in a different directory or a different build/version. The OS will recognize the library if the full path is the same than another one already loaded and it will share it instead of loading it a second time.

The other library can load its plugins from another path because it written to not depend on PATH and they are his own plugins.

Have you try to update the process's environment variables from the code before loading the Dll? That will not depends on a starter process.

PRouleau
  • 542
  • 4
  • 12
  • 1
    This isn't true -- many large 3rd-party libraries use dynamic library loading to implement plugin systems. The functions must be marked `extern "C"` blocks to [ensure c-linkage](https://stackoverflow.com/a/1041880/3053072) and prevent name mangling. It's true that the Windows API specifies an entry point for DLL's for when they're loaded (among other things). However, this is platform-dependent. – Joshua Hyatt Nov 26 '19 at 01:18