[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ra_load and wrong loads

From: Arkadiusz Miskiewicz <misiek_at_pld.ORG.PL>
Date: 2002-07-31 21:04:16 CEST

Justin Erenkrantz <jerenkrantz@apache.org> writes:

> > Compile with --enable-dso and you will see the problem.
>
> The code in load_ra_module is completely bogus.
>
> /* ### fix the .so part */
> libname = apr_psprintf (pool, "libsvn_ra_%s.so", ra_name);
> funcname = apr_psprintf (pool, "svn_ra_%s_init", ra_name);
>
> .so isn't guaranteed. Darwin uses .dylib. There are many other
> variants, too.
>
> If you really want to make this work with .so, you would have to
> link the ra_* libraries with the "-module" flag and override
> the default name to be libsvn_ra_*.so.
>
> This is the strategy that httpd-2.0 uses for its DSO modules. You
> would also place them in a separate directory than lib/ (ie
> modules/).
So what (IMO) should be done is when --enable-dso is specified:

- move dso modules to
  $(libdir}/subversion/${SVN_VER_MAJOR}.${SVN_VER_MINOR}.${SVN_VER_MICRO}
  and then move SVN_VER_XYZ to configure.in

  or

  move version from build.conf to configure.in, pass it to
  load_ra_module() and place all dso modules - libxyz-${version}.so
  - in $(libdir}/subversion/ (I prefer this)

- use -module

- rename modules to xyz.so or libxyz.so

- remove versioning (-avoid-version) to get libxyz.so instead
  of libxyz.so.0.0.0

Something else? +1 for that?
  
> Since the ra_loader code only looks for specific modules anyway,
> I'm not sure what the rationale is for having them dynamically
> loaded. There isn't a way to register your provider with the
> ra functions without a recompile anyway.
Load all *.so from $(libdir}/subversion/ ?

> So, I'd rather see all of this code thrown out. -- justin

-- 
Arkadiusz Mi¶kiewicz   IPv6 ready PLD Linux at http://www.pld.org.pl
misiek(at)pld.org.pl   AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PWr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 31 21:20:35 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.