dlerror() returns null string - Aix

This is a discussion on dlerror() returns null string - Aix ; Am I doing something wrong? I'm having problems getting an app to dlopen() a application shared library that references another 'utilities' library. It works fine with the original 'utilities' library, but the main app contains (and exports) static copies of ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: dlerror() returns null string

  1. dlerror() returns null string

    Am I doing something wrong?

    I'm having problems getting an app to dlopen() a application shared
    library that references another 'utilities' library. It works fine
    with the original 'utilities' library, but the main app contains (and
    exports) static copies of a bunch of those utility functions. This
    causes a bunch of duplicate symbol warnings when I build the
    application shared library.

    I'm trying to build a cut-down version of the utilities library to
    eliminate the warnings, but everytime I remove something from the
    utilities, dlopen() fails.

    Since there is so much stuff in the utilities library, it's very
    difficult to determine what symbols are missing at dlopen() time. I
    just get an ENOEXEC. And dlerror() doesn't seem to be of much help.
    If there are more than 1 or 2 symbols dlopen() can't resolve, dlerror()
    doesn't list *any* of the missing stuff. You either get a generic
    "Exec Format Error" message or nothing. I don't know why dlerror can't
    be made to at least list the first missing symbol, so I can resolve the
    problem a symbol at a time instead of having no information to go on.

    I found some documentation for a 'loadquery' function (which seems to
    be non-standard - at least Linux doesn't have it), and I tried that.
    In the case where dlerror() was returning a null string, loadquery
    returns 0 and fills no string pointers into my buffer.

    I tried stepping through this in dbx. After the dlopen() failed, I
    typed 'print dlerror()' and then dumped out the buffer it returned.
    The pointer is not NULL, and there's an explicit null character at the
    beginning of the returned buffer:

    debug--> p dlerror()
    0xf0072234
    debug--> 0xf0072234/100c
    0xf0072234: '\0' 'a' 'n' 'n' 'o' 't' ' ' 'r' 'u' 'n' ' ' 'a' ' ' 'f'
    'i' 'l'
    0xf0072244: 'e' ' ' 't' 'h' 'a' 't' ' ' 'd' 'o' 'e' 's' ' ' 'n' 'o'
    't' ' '
    0xf0072254: 'h' 'a' 'v' 'e' ' ' 'a' ' ' 'v' 'a' 'l' 'i' 'd' ' ' 'f'
    'o' 'r'
    0xf0072264: 'm' 'a' 't' '.' '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0'
    '\0' '\0' '\0' '\0'


    Is there another set of tools to tell you for a given set of modules
    whether they can be loaded together (beyond using the 'nm' command and
    a lot of legwork to figure it out)? For what it's worth, I'm
    developing on AIX 4.3.

    Thanks,
    Rob


  2. Re: dlerror() returns null string

    Rob Y wrote:
    > I'm having problems getting an app to dlopen() a application shared
    > library that references another 'utilities' library. It works fine
    > with the original 'utilities' library, but the main app contains (and
    > exports) static copies of a bunch of those utility functions. This
    > causes a bunch of duplicate symbol warnings when I build the
    > application shared library.




    > Is there another set of tools to tell you for a given set of modules
    > whether they can be loaded together (beyond using the 'nm' command and
    > a lot of legwork to figure it out)? For what it's worth, I'm
    > developing on AIX 4.3.


    Good heavens, why?

    At the very least, we'll need to see your command line. How
    are you referencing the symbols in the main app? IOW there's
    not enough information here to really provide direction.

  3. Re: dlerror() returns null string

    Hi,

    I don't have much idea about your code, but did you follow a few
    things? These are from the UNIX03 standards:
    (http://www.unix.org/single_unix_specification/)

    DESCRIPTION

    The dlerror() function shall return a null-terminated character
    string (with no trailing ) that describes the last error that
    occurred during dynamic linking processing. If no dynamic linking
    errors have occurred since the last invocation of dlerror(), dlerror()
    shall return NULL. Thus, invoking dlerror() a second time, immediately
    following a prior invocation, shall result in NULL being returned.

    The dlerror() function need not be reentrant. A function that is
    not required to be reentrant is not required to be thread-safe.

    RETURN VALUE

    If successful, dlerror() shall return a null-terminated character
    string; otherwise, NULL shall be returned.
    APPLICATION USAGE

    The messages returned by dlerror() may reside in a static buffer
    that is overwritten on each call to dlerror(). Application code should
    not write to this buffer. Programs wishing to preserve an error message
    should make their own copies of that message. Depending on the
    application environment with respect to asynchronous execution events,
    such as signals or other asynchronous computation sharing the address
    space, conforming applications should use a critical section to
    retrieve the error pointer and buffer.

    Thanks and regards,
    Rajbir Bhattacharjee



    Rob Y wrote:
    > Am I doing something wrong?
    >
    > I'm having problems getting an app to dlopen() a application shared
    > library that references another 'utilities' library. It works fine
    > with the original 'utilities' library, but the main app contains (and
    > exports) static copies of a bunch of those utility functions. This
    > causes a bunch of duplicate symbol warnings when I build the
    > application shared library.
    >
    > I'm trying to build a cut-down version of the utilities library to
    > eliminate the warnings, but everytime I remove something from the
    > utilities, dlopen() fails.
    >
    > Since there is so much stuff in the utilities library, it's very
    > difficult to determine what symbols are missing at dlopen() time. I
    > just get an ENOEXEC. And dlerror() doesn't seem to be of much help.
    > If there are more than 1 or 2 symbols dlopen() can't resolve, dlerror()
    > doesn't list *any* of the missing stuff. You either get a generic
    > "Exec Format Error" message or nothing. I don't know why dlerror can't
    > be made to at least list the first missing symbol, so I can resolve the
    > problem a symbol at a time instead of having no information to go on.
    >
    > I found some documentation for a 'loadquery' function (which seems to
    > be non-standard - at least Linux doesn't have it), and I tried that.
    > In the case where dlerror() was returning a null string, loadquery
    > returns 0 and fills no string pointers into my buffer.
    >
    > I tried stepping through this in dbx. After the dlopen() failed, I
    > typed 'print dlerror()' and then dumped out the buffer it returned.
    > The pointer is not NULL, and there's an explicit null character at the
    > beginning of the returned buffer:
    >
    > debug--> p dlerror()
    > 0xf0072234
    > debug--> 0xf0072234/100c
    > 0xf0072234: '\0' 'a' 'n' 'n' 'o' 't' ' ' 'r' 'u' 'n' ' ' 'a' ' ' 'f'
    > 'i' 'l'
    > 0xf0072244: 'e' ' ' 't' 'h' 'a' 't' ' ' 'd' 'o' 'e' 's' ' ' 'n' 'o'
    > 't' ' '
    > 0xf0072254: 'h' 'a' 'v' 'e' ' ' 'a' ' ' 'v' 'a' 'l' 'i' 'd' ' ' 'f'
    > 'o' 'r'
    > 0xf0072264: 'm' 'a' 't' '.' '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0'
    > '\0' '\0' '\0' '\0'
    >
    >
    > Is there another set of tools to tell you for a given set of modules
    > whether they can be loaded together (beyond using the 'nm' command and
    > a lot of legwork to figure it out)? For what it's worth, I'm
    > developing on AIX 4.3.
    >
    > Thanks,
    > Rob



  4. Re: dlerror() returns null string

    One more doubt, are you doing a dlerror() inside the code as well. If
    you are doing so, then when you do a dlerror() in dbx again, or if you
    do dlerror() twice in dbx, you might get an empty string.

    "If no dynamic linking errors have occurred since the last invocation
    of dlerror(), dlerror() shall return NULL. Thus, invoking dlerror() a
    second time, immediately following a prior invocation, shall result in
    NULL being returned."

    Thanks and regards,
    Rajbir Bhattacharjee
    a
    rajbir wrote:
    > Hi,
    >
    > I don't have much idea about your code, but did you follow a few
    > things? These are from the UNIX03 standards:
    > (http://www.unix.org/single_unix_specification/)
    >
    > DESCRIPTION
    >
    > The dlerror() function shall return a null-terminated character
    > string (with no trailing ) that describes the last error that
    > occurred during dynamic linking processing. If no dynamic linking
    > errors have occurred since the last invocation of dlerror(), dlerror()
    > shall return NULL. Thus, invoking dlerror() a second time, immediately
    > following a prior invocation, shall result in NULL being returned.
    >
    > The dlerror() function need not be reentrant. A function that is
    > not required to be reentrant is not required to be thread-safe.
    >
    > RETURN VALUE
    >
    > If successful, dlerror() shall return a null-terminated character
    > string; otherwise, NULL shall be returned.
    > APPLICATION USAGE
    >
    > The messages returned by dlerror() may reside in a static buffer
    > that is overwritten on each call to dlerror(). Application code should
    > not write to this buffer. Programs wishing to preserve an error message
    > should make their own copies of that message. Depending on the
    > application environment with respect to asynchronous execution events,
    > such as signals or other asynchronous computation sharing the address
    > space, conforming applications should use a critical section to
    > retrieve the error pointer and buffer.
    >
    > Thanks and regards,
    > Rajbir Bhattacharjee
    >
    >
    >
    > Rob Y wrote:
    > > Am I doing something wrong?
    > >
    > > I'm having problems getting an app to dlopen() a application shared
    > > library that references another 'utilities' library. It works fine
    > > with the original 'utilities' library, but the main app contains (and
    > > exports) static copies of a bunch of those utility functions. This
    > > causes a bunch of duplicate symbol warnings when I build the
    > > application shared library.
    > >
    > > I'm trying to build a cut-down version of the utilities library to
    > > eliminate the warnings, but everytime I remove something from the
    > > utilities, dlopen() fails.
    > >
    > > Since there is so much stuff in the utilities library, it's very
    > > difficult to determine what symbols are missing at dlopen() time. I
    > > just get an ENOEXEC. And dlerror() doesn't seem to be of much help.
    > > If there are more than 1 or 2 symbols dlopen() can't resolve, dlerror()
    > > doesn't list *any* of the missing stuff. You either get a generic
    > > "Exec Format Error" message or nothing. I don't know why dlerror can't
    > > be made to at least list the first missing symbol, so I can resolve the
    > > problem a symbol at a time instead of having no information to go on.
    > >
    > > I found some documentation for a 'loadquery' function (which seems to
    > > be non-standard - at least Linux doesn't have it), and I tried that.
    > > In the case where dlerror() was returning a null string, loadquery
    > > returns 0 and fills no string pointers into my buffer.
    > >
    > > I tried stepping through this in dbx. After the dlopen() failed, I
    > > typed 'print dlerror()' and then dumped out the buffer it returned.
    > > The pointer is not NULL, and there's an explicit null character at the
    > > beginning of the returned buffer:
    > >
    > > debug--> p dlerror()
    > > 0xf0072234
    > > debug--> 0xf0072234/100c
    > > 0xf0072234: '\0' 'a' 'n' 'n' 'o' 't' ' ' 'r' 'u' 'n' ' ' 'a' ' ' 'f'
    > > 'i' 'l'
    > > 0xf0072244: 'e' ' ' 't' 'h' 'a' 't' ' ' 'd' 'o' 'e' 's' ' ' 'n' 'o'
    > > 't' ' '
    > > 0xf0072254: 'h' 'a' 'v' 'e' ' ' 'a' ' ' 'v' 'a' 'l' 'i' 'd' ' ' 'f'
    > > 'o' 'r'
    > > 0xf0072264: 'm' 'a' 't' '.' '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0'
    > > '\0' '\0' '\0' '\0'
    > >
    > >
    > > Is there another set of tools to tell you for a given set of modules
    > > whether they can be loaded together (beyond using the 'nm' command and
    > > a lot of legwork to figure it out)? For what it's worth, I'm
    > > developing on AIX 4.3.
    > >
    > > Thanks,
    > > Rob



+ Reply to Thread