Balazs Scheidler writes: > 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 symbols we're looking for are the functions defined in the database engine client libraries. > 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? > In fact, I was close to suspecting that this is a self-inflicted problem, see this note in configure.in: dnl note to self: is this hack a consequence of dnl using RTLD_LAZY in the first place?? However, removing this check and treating FreeBSD like any other OS does not change the behaviour. The FreeBSD dlopen man page states that RTLD_LAZY is preferred for reasons of efficiency. This is apparently why someone added the check to configure.in > 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 absolutely agree that this is going to cause trouble at some point, but there's no way to even compile the code if the symbol is not defined. > 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 This used to work on FreeBSD > 2) dlopen(NULL) and use dlsym() with the returned handle This won't even load the drivers on FreeBSD. Does it work on one of your platforms? Even worse, after reverting the above changes, custom functions stopped working on my system too. I'm kinda screwed now. Frankly, this problem is a little above my head. Any help is greatly appreciated. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ------------------------------------------------------------------------- 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
