You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2006/06/23 01:05:19 UTC

neon/serf selection

I've noticed that my neon-using svn client attempts to load the
ra_serf library dynamically. Since I'm using Linux I have APR_HAS_DSO
set but I don't use --enable-dso so libsvn_ra is explicitly linked to
libsvn_ra_dav. I don't have serf installed and I don't build ra_serf.
Despite this Subversion's DSO code attempts to load ra_serf at
runtime.  Is it supposed to work this way?

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: neon/serf selection

Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@xbc.nu> writes:

> Philip Martin wrote:
>> I've noticed that my neon-using svn client attempts to load the
>> ra_serf library dynamically. Since I'm using Linux I have APR_HAS_DSO
>> set but I don't use --enable-dso so libsvn_ra is explicitly linked to
>> libsvn_ra_dav. I don't have serf installed and I don't build ra_serf.
>> Despite this Subversion's DSO code attempts to load ra_serf at
>> runtime.  Is it supposed to work this way?
>>   
> It's a "feature". Same happens with ra_dav if I don't build neon, and
> the dam' thing actually errors out. That's something I don't actually
> understand, given that the ra_loader is suppoesd to ignore library load
> errors.

It means one cannot reliably run the regression tests unless one knows
what is installed.  The DSO code looks in the install directory for
the "missing" library even when run from the build directory, and if a
library is found in the install dir there is no guarantee that it is
compatible with the build (that might explain your errors).  Even if
the installed library is ABI compatible having two modules handling
the same scheme doesn't seem sensible, I suppose one simply overrrides
the other.

Does anyone think the current behaviour is correct?

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: neon/serf selection

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 6/23/06, Branko Čibej <br...@xbc.nu> wrote:
> It's a "feature". Same happens with ra_dav if I don't build neon, and
> the dam' thing actually errors out. That's something I don't actually
> understand, given that the ra_loader is suppoesd to ignore library load
> errors.

I'm pretty sure that I had patches to ra_loader to resolve this, but I
was told that the current behavior is what we want.  *shrug*  --
justin

Re: neon/serf selection

Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
> I've noticed that my neon-using svn client attempts to load the
> ra_serf library dynamically. Since I'm using Linux I have APR_HAS_DSO
> set but I don't use --enable-dso so libsvn_ra is explicitly linked to
> libsvn_ra_dav. I don't have serf installed and I don't build ra_serf.
> Despite this Subversion's DSO code attempts to load ra_serf at
> runtime.  Is it supposed to work this way?
>   
It's a "feature". Same happens with ra_dav if I don't build neon, and
the dam' thing actually errors out. That's something I don't actually
understand, given that the ra_loader is suppoesd to ignore library load
errors.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org