[2 replies to your message, Greg, so that svn-only stuff doesn't bore
the APR folks.]
On Mon, 10 Jun 2002, Greg Stein wrote:
> On Mon, Jun 10, 2002 at 01:44:05AM -0700, David Mankin wrote:
> >...
> > I configured and built svn with the --enable-maintainer-mode and
> > --disable-shared.
> >...
> > However, I think there might also be a bug (or several) in Subversion.
> > I compiled with --disable-shared, and yet subversion is still trying to
> > load a dynamic library. I'm trying to do an HTTP checkout, and yet it's
> > trying to load a dynamic library for RA local. Both of these seem like
> > they might be problems.
>
> Not a problem, actually.
>
> The RA layer knows that ra_dav was linked in, and that ra_local is *not*
> linked in. Thus, it attempts to load it dynamically since the DSO facilities
> are available in APR.
>
> The --disable-shared switch controls whether shared libraries are *built*.
> It doesn't control whether SVN will attempt to find RA modules that were not
> linked into the app.
Since --disable-shared doesn't prevent module loading, I wonder if there
is a good reason to have a --don't-try-to-load-modules flag on the
compilation or running of the svn client. I can easily envision a case
where a particular version of svn (e.g. 1.0) is installed (with shared
libraries accessible in /usr/local/lib, e.g.) but after compiling a
static svn at a different version (1.1) without ra_local, you wouldn't
want it loading in the installed libraries just because they're there...
But maybe I've just got too-active an imagination.
> > [A fourth thing that may be an issue: when I modified dso.c and then
> > re-ran make from the top-level svn makefile, it didn't re-link the svn
> > binary, even though the apr.la (?) library had changed. I had to touch
> > clients/cmdline/main.c in order to force make to rebuild svn.]
>
> Hmm. That does seem to be a problem. Could you file an issue about that?
Will do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 11 07:48:05 2002