Avoiding call to dlopen

Pawel_C_ · ‎10-10-2012

Hi,

I'm using Intel MKL 10.2.5.035 in the UNIX-based system I'm working on. There's a requirement to use dynamic libraries and each dependency (MKL library necessary to run the C code in that case) is registered within the system and copied to the system specific location during compilation/liniking (another specific tool is used here). All registered libraries are automatically loaded during the sytem initialization and available. There's no control over LD_LIBRARY_PATH or other means of pointing the system to the right path except the mentioned registration. Quite a specific setup, but that's how it looks like.

The problem is that during execution of some (all?) of the Intel MKL routines (I tried dgemm() and one of the solvers) there's a call to mkl_serv_load_dll() which eventually calls dlopen() on libmkl_p4m3.so. In that case it looks in the path specific to libmkl_core.so (as I wrote, each library is copied into different folder), which - I think - is the place it thinks all other libraries should be placed. It fails and the execution of the code is stopped. So my question is, given that all libraries are preloaded and available, is there any way to avoid direct call to dlopen, e.g. by setting an environment variable. I believe I can hack the system somehow to point the code being executed to the right place, but I'd like to avoid that as long as there's a chance to find an elegant solution.

Cheers,

Pawel

barragan_villanueva_ · ‎10-11-2012

Hi, Currently in MKL any arch-specific libraries are loaded at run-time according to host architecture. So, in your case libmkl_p4m3.so is required. In MKL 10.3.6 version there was implemented secure loading of arch-specific libraries from the path where located MKL core library which namely was used during linking. So, my recommendation is to upgrade your MKL to 10.3 latest update or MKL 11.0. As a workaround, please try to preload this library before execution: % LD_PRELOAD=/path/to/the/libmkl_p4m3.so /your/executable "with arguments"

Pawel_C_ · ‎10-11-2012

Victor, thank you for the response. Unfortunately, I don't think upgrading MKL will solve the problem anyway. I'll try to clarify the deployment process on the system I'm using. There are two different machines, call them master (M) and satellite (S). The architecture of both is similar enough to use the same set of MKL libraries but this is where the good news ends. The assumption is that there's no control over the initialization of both, hence no way of updating the environment. When I deploy code that uses shared libraries (e.g. MKL) I need to use a special procedure: 1) Register each library separately within the system (that operation copies .so file to a specific locations on M and S, each .so file is placed in a different path related to the registration id: /path/rid1/libmkl_core.so, /path/rid2/libmkl_intel.so, etc.). 2) Use a special compilation script and set registered libraries as a dependency; this script produces shared object for M and relocatable object for S (don't ask me why) - there's linking for M and only compilation for S. 3) Use a special mechanism to execute deployed code: underneath a special container code is generated (different for M and S) that is linked with shared object on M or linked with relocatable object on S, depending on which machine it will be executed on; paths to the MKL libraries are resolved from the information stored during libraries registration. Container with my code is compiled, linked and executed within the system (no forking, so no way to use updated environment). So, there's no way to use LD_PRELOAD. I can use -rpath as a compilation script parameter in 2), but it works only for M, as there's no linking when the object for S is created. As far as I could see from stack trace, when dlopen() is executed it indeed searches for the libmkl_p4ms.so also in the path where libmkl_core.so is placed, so I think the secure loading is already available for UNIX-like systems (from 10.3.6 release notes it seems like the secure loading was added to the Windows version). As all the libraries I set as dependency for the code are opened during the execution I can add libmkl_p4m3.so to that list and have all the symbols available. Unfortunately, direct call to dlopen on that library can't be resolved. That brought me to the question, if it's possible to avoid the call to dlopen, given that the library is already loaded. Thanks, Pawel

barragan_villanueva_ · ‎10-16-2012

Pawel, Thanks for your details on your problem. Unfortunately, MKL does not have any contol in environment to avoid loading of arch-specific dynamic libraries. Maybe, static linking with MKL would be resonable for your usage model.