This is a discussion on getting dlopen() to link against my main executable within the AIX Operating System forums, part of the Unix Operating Systems category; --> I'm trying to use dlopen() to provide support for loadable modules in my application. I've got the basic mechanism ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| I'm trying to use dlopen() to provide support for loadable modules in my application. I've got the basic mechanism working with a trivial shared library that doesn't make any outside calls, but I need to export some library functions in the main application to make them available to the run-time loaded modules. And I need to call the versions in the main app (can't link in separate copies, because initializations have all ready been done to the libraries inside the main app). So far, I'm getting "Exec format errors" on my dlopen calls when I build a shared library that wants to link to libraries inside the main app. I assume this means that the linker failed to resolve some stuff. In order to get the shared library to build, I provided an app.exp file that listed all the symbols I want to resolve from the main app and used -bIapp.exp on my link statement. That 'works', but I don't know if it's the correct way to do it. My main app isn't really a shared library, and I only know about the .exp file mechanism as it relates to shared libraries. I also tried using -bexpall and -brtl on the link statement for my main app, in case these are needed to get it to support exporting symbols. Still no luck - and just the Exec format error message to guide me. So... 1. Is there a more correct way to get my shared library to 'know' about the symbols it needs from the main app? 2. Is there a way to find out what symbols aren't being resolved at run time? 3. Am I just doing this completely wrong? Thanks, Rob |
| ||||
| I seem to be making progress. I moved some stuff from a library I was statically linking to my shared library directly into the base app instead. Now my shared library can access that stuff, as well as other stuff in the base app. So, it must have been a case of stuff that I thought was in the base app not really being there. Because I had put it in my app.exp file, the linker let me build the dynamic module, but dlopen still failed because of the missing symbols. Interestingly enough, when I got the missing symbols down to a manageable level, I started getting meaningful error messages out of dlerror(). Stuff like: 0509-130 Symbol resolution failed for /u/rob/em/em/emapps/TESTDLL.dll because: 0509-136 Symbol InitKey (number 6) is not exported from dependent module x1. 0509-192 Examine .loader secti which was really helpful. 'dependent module x1' is referring to my base app (the executable's called x1). So, it seems like I'm on the right track. Still, if anybody feels like commenting on 1. whether there's an easier way 2. whether the -bexpall and -brtl options are *really* needed in the main app and/or the shared library 3. whether an 'exp' file is the correct way to tell the shared library what functions are available in the main app. I'd appreciate it. Thanks, Rob |