On Fri, 2008-08-01 at 10:05 +0200, Markus Hoenicka wrote:
> Quoting Balazs Scheidler <[EMAIL PROTECTED]>:
>
> > If these functions are indeed exported by the driver module, I don't see
> > why you are using RTLD_NEXT at all. You could simply resolve the symbol
> > from the shared object itself. Or am I missing something?
> >
> > We need to test the functionality on AIX, so we will. I drop you an
> > email once we did that.
> >
>
> Well, I don't wear a black belt in juggling shared objects so I may be
> a bit off here, but RTLD_NEXT was required to get this code to work
> under FreeBSD. Using the driver handle does not work for me on that
> platform, whereas it does work on Linux and on Cygwin. If you are
> familiar with this kind of stuff, feel free to review the code and
> suggest a better, portable way to do this. I wouldn't be too surprised
> if I screwed something up (although it works on all platforms that I
> have access to).
Hmm, in my understanding RTLD_NEXT means that the given symbol must be
resolved in all libraries loaded before the one that issues the dlsym()
call. From the Linux manual page of dlsym():
There are two special pseudo-handles, RTLD_DEFAULT and RTLD_NEXT. The
former will find the first occurrence of the desired
symbol using the default library search order. The latter will find the
next occurrence of a function in the search order
after the current library. This allows one to provide a wrapper around
a function in another shared library.
Where are these symbols defined? in the dbd driver file, or by the
client library of the given database engine?
If the first, then I don't see why RTLD_NEXT is needed, if the second,
then I can understand.
The reason why FreeBSD behaves differently might also be caused by this
test:
case $host in
*-*-*bsd*)
dlsym_handle=0
dlopen_flag="RTLD_LAZY" ;;
*)
dlsym_handle=1
dlopen_flag="RTLD_NOW" ;;
esac
e.g. all platforms except BSD use RTLD_NOW, but BSDs use RTLD_LAZY. Why is that?
And another thing, you seem to define RTLD_NEXT if it is undefined:
#ifndef RTLD_NEXT
#define RTLD_NEXT ((void *) -1) /* taken from FreeBSD */
#endif
This is almost certainly not correct. Platforms that do not have RTLD_NEXT
defined probably don't support it. For instance AIX 5.2 has no support
for RTLD_NEXT, I even found a 'what changed' document for AIX 5.3, which
announces RTLD_NEXT as a new feature.
I dunno what needs to be specified for dlsym() if I don't have a handle
to look up symbols from. .....
I think I've found it: both the AIX and Linux manual page for dlopen state:
"If filename is NULL, then the returned handle is for the main program. "
If my assumption is true and the symbols to be resolved are indeed
exported by the database client library, which is linked in because
of the database driver, then either of these options would work:
1) use RTLD_NEXT where available
2) dlopen(NULL) and use dlsym() with the returned handle
--
Bazsi
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
