[PATCH] Re: Recent libsvn_fs stuff breaks --enable-dso

["Peter N. Lundblad" <pe...@famlundblad.se>]

On Tue, 12 Apr 2005, Greg Hudson wrote:

> On Mon, 2005-04-11 at 20:21, Philip Martin wrote:
> > Using --enable-dso I get
>
> > I suppose we could make the client link against libsvn_fs explicitly,
> > but does that sensible for the --enable-dso case?
>
> I don't have a good answer here. :/  I'll think on it, but other
> people's ideas are welcome.

Well, since we use functions from libsvn_fs in the client, I suppose we
should link explicitly to it. We don't drag in any of the FS
implementations. That's the point of --enable-dso, isn't it? (See attached
patch. It fixes the problem for me.)

(BTW, I don't understand why this started happening, since other libraries
drag in libsvn_fs anyway. Is it a link ordering problem? I dunno nothing.)

Regards,
//Peter

Re: [PATCH] Re: Recent libsvn_fs stuff breaks --enable-dso

["Peter N. Lundblad" <pe...@famlundblad.se>]

On Tue, 12 Apr 2005, Max Bowsher wrote:

> Peter N. Lundblad wrote:
> >> On Tue, 12 Apr 2005, Greg Hudson wrote:
> >>
> >>> On Mon, 2005-04-11 at 20:21, Philip Martin wrote:
> >>>> Using --enable-dso I get
> >>>
> >>>> I suppose we could make the client link against libsvn_fs explicitly,
> >>>> but does that sensible for the --enable-dso case?
> >>>
> >>> I don't have a good answer here. :/  I'll think on it, but other
> >>> people's ideas are welcome.
> >>
> >> Well, since we use functions from libsvn_fs in the client, I suppose we
> >> should link explicitly to it. We don't drag in any of the FS
> >> implementations. That's the point of --enable-dso, isn't it? (See
> >> attached
> >> patch. It fixes the problem for me.)
> >>
> >> (BTW, I don't understand why this started happening, since other
> >> libraries
> >> drag in libsvn_fs anyway. Is it a link ordering problem? I dunno
> >> nothing.)
>
> Works, I suppose, but seems slightly clumsy.
>
> Before now, you could use an --enable-dso svn binary to do network RA
> operations without even having a libsvn_fs binary on the computer.
>
Yes, it is time for me to say bah! I see that now, a few hours later.

I don't know about the print_modules stuff. The init stuff could be solved
with svn_ra_initialize being added. Note that we can change the RA lib
init function signature before 1.2, when the ABI gets frozen.

Thinking about the module printing, it sems like a design mistake to call
it from the cmdline client. I think svn_ra_print_modules should be
extended to handle this situation.

Regards,
//Peter

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

Re: [PATCH] Re: Recent libsvn_fs stuff breaks --enable-dso

[Max Bowsher <ma...@ukf.net>]

Peter N. Lundblad wrote:
>> On Tue, 12 Apr 2005, Greg Hudson wrote:
>>
>>> On Mon, 2005-04-11 at 20:21, Philip Martin wrote:
>>>> Using --enable-dso I get
>>>
>>>> I suppose we could make the client link against libsvn_fs explicitly,
>>>> but does that sensible for the --enable-dso case?
>>>
>>> I don't have a good answer here. :/  I'll think on it, but other
>>> people's ideas are welcome.
>>
>> Well, since we use functions from libsvn_fs in the client, I suppose we
>> should link explicitly to it. We don't drag in any of the FS
>> implementations. That's the point of --enable-dso, isn't it? (See 
>> attached
>> patch. It fixes the problem for me.)
>>
>> (BTW, I don't understand why this started happening, since other 
>> libraries
>> drag in libsvn_fs anyway. Is it a link ordering problem? I dunno 
>> nothing.)

Works, I suppose, but seems slightly clumsy.

Before now, you could use an --enable-dso svn binary to do network RA 
operations without even having a libsvn_fs binary on the computer.

The libsvn_fs dependency is really an implementation detail of ra_local.

Max. 


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