getting dlopen() to link against my main executable - Aix

This is a discussion on getting dlopen() to link against my main executable - Aix ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: getting dlopen() to link against my main executable

  1. getting dlopen() to link against my main executable

    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


  2. Re: getting dlopen() to link against my main executable

    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


+ Reply to Thread