Hello,

I wrote a little app which uses a shared library (DLL).  Normally, I
load the shlib using "dlopen()", and find the functions I want using
"dlsym()".  However, I am attempting to get rid of any overhead and am
curious about a little problem I'm having.

I decided to make a function in my shlib called
"get_function_list()".  When I start my program, I open the shlib
using "dlopen()" and use "dlsym()" to get the "get_function_list()"
function.  That function returns a list of all the methods inside the
shlib that I will be using.

Therein lies the problem.  For any function in my shlib, the address
returned by dlsym() and the address returned in my function list are
different.  I've placed a bunch of debug code in both my shlib and my
sample app to printf the address of the function.  Using dlsym(), the
function I want is located at "0x2405e0e8", but the address in my list
is "0x24032e38".  Unfortunately, the difference between dlsym and my
list is not always 2b2b0 as in this case.

Has anyone ever experienced this or does anyone have any insight in to
the issue?

Any help will be greatly appreciated.

Thanks!

[ Post a follow-up to this message ]

"maven22" <mattvenables@gmail.com> writes:

> Therein lies the problem.  For any function in my shlib, the address
> returned by dlsym() and the address returned in my function list are
> different.

This in itself need not be a problem -- some platform use quite
complicated set-up to call a function from shared library.

For example, on HP-UX/PA-RISC, there are 3 addresses for a function
that you link directly (not via dlsym()) from a shared library:
the "import stub" (in the calling exe/DSO), the "export stub"
in the DSO itself, and the actual function definition.

> Has anyone ever experienced this or does anyone have any insight in to
> the issue?

I was unable to replicate the behaviour you described on any platform
I tried it on.

You may wish to provide clues as to which platform you are actually
interested in, and also construct a trivial example demonstrating
the "problem".

It is somewhat likely that you have a bug in your code, which will
be revealed to you once you post your test case (provided you don't
discover your bug yourself while preparing the small test case).

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Thanks, I'll throw together a quick log.  In the meantime, this may be
of some help:
1. It works fine on a windows platform
2. I'm using it in z/OS when it breaks

[ Post a follow-up to this message ]