Greg, never mind. I now totally understand what you're doing in
ra_loader.c. I just didn't read carefully enough. :)
Whether my program be svn itself or a simple test program, all I need
to do is:
* call svn_client_init_ra_libs, which hands me a baton. (The baton
is actually a hash of ra vtables.)
* pass the baton to svn_client_get_ra_library, and receive any
vtable I want.
And it looks like this will work in both static-link *and* DSO
situations.
Greg, you rock. :) Thanks.
Greg Stein <gstein@lyra.org> writes:
> On Thu, Mar 08, 2001 at 03:40:09PM -0600, Ben Collins-Sussman wrote:
> >
> > Greg (Stein):
>
> gjs or gstein :-) ... although, the context of the topic, would probably
> make plain old Greg work just fine :-)
>
> > We need the ability to fetch a hash full of available RA vtables. The
> > client needs this routine, and so do RA test programs. (I'm working
> > on ra-local-test right now.)
>
> Expose the hash of them? Or return the ra_plugin used for a specific URL? We
> have the latter. I don't understand why you would need the former.
>
> > I discovered your implementation of svn_client_init_ra_libs() -- which
> > seems to do exactly that! The problem is that it always tries to
> > manually load DSOs.
>
> Euh, no it doesn't :-)
>
> If the ra_libraries[] global has initializer functions already in it, then
> init_ra_libs doesn't try to load a DSO. Check your
> SVN_LIBSVN_CLIENT_LINKS_RA_* defines in svn_private_config.h (top-level
> directory)
>
> > We need to expand the abilities of this routine. It needs to return a
> > hash of available RA vtables *regardless* of how the binary was
> > compiled; it should work in a statically linked universe too.
> >
> > Do you know how to make this happen?
>
> It does, although the hash is hidden within the baton. It works for all
> three of the following cases, in order of preference:
>
> 1) if DSO loading is available AND --enable-shared was passed to configure
> (well, the absence of --disable-shared, really), THEN use dynamic loading
>
> 2) if DSO loading is available AND --disable-shared was passed, THEN use
> static linking
>
> 3) if DSO loading is NOT available, THEN use static linking
>
> There is a fourth case, which we do not support at this time:
>
> 4) if DSO loading is available AND --enable-shared was passed, THEN use
> shared-library linking
> [ link against the .so rather than the .a; currently if a .so is
> produced, then we always dynamically load it ]
>
>
> So... I'm a bit unclear on the API changes that you'd like to see. We
> certainly have the correct mechanics occuring; the question is how much we
> expose.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:25 2006