The use of dladdr in OpenAccess

Today, I was wondering if I can use archive version of OpenAccess libraries when I was building the newest version of OpenAccess DM3. So, I followed the steps at the previous post to build archive versions of OpenAccess libraries. Everything worked fine at first but when I started to load the design library, OpenAccess complains about the wrong plug-ins installation path. I know this error probably come from the installation path is not correcly obtained from the experience.. After delving into the source code at oaCommonInstallDir.cpp for a while, I found out that the suspicious code is

238 InstallDir::getLibPath()
239 {
240     if (libPath.size()) {
241     return libPath.c_str();
242     }
243
244     Dl_info info = { NULL, NULL, NULL, NULL };
245
246     if (!dladdr((void*) dirSep, &info)) {
247     return libPath.c_str();
248     }
249
250     libPath = info.dli_fname;

The Dl_info filled in by dladdr has the wrong value at dli_fname field. Why??

Because all the OA libraries are in the form of archive libraries, the address of variable dirSep is located at the main executable rather than the shared object file. So, the dli_fname resolved may not be right, in fact, it is the argv[0] of the calling process. Check this out (See item 2 of section BUGS at here).

If addr lies in the main executable rather than in a shared library, the pathname returned in dli_fname may
not be correct. The pathname is taken directly from argv[0] of the calling process. When executing a program
specified by its full pathname, most shells set argv[0] to the pathname. But this is not required of shells 
or guaranteed by the operating system.

It turns out that the module oaCommon must be linked into the main executable in the form of shared object file in order for OA to generate the right installation path from dladdr. I made it so, but the experiment conducted later still shows that the OA developers don't even consider this be an use model. The oaTurboDMServer launched by the OA system still tries to load shared object files, like liboaTech.so, liboaDesign.so, etc. With all these libraries must be in the form of shared libraries, I think it's time to give up. :)