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

Re: [PATCH] cancellation, take one

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2003-02-18 02:32:17 CET

On Monday, February 17, 2003, at 06:57 PM, Greg Hudson wrote:

> On Mon, 2003-02-17 at 17:42, Branko Čibej wrote:
>> There's absolutely nothing wrong with that kind of dependencies. Any
>> normal linker can resolve them; at worst, you'll get one of those
>> files
>> on the link line twice.
>
> Not so.
>
> In the Unix world, with shared libraries, circular dependencies are not
> generally an issue because the entire library is linked in regardless
> of
> what symbols are called for. (Though IRIX manages to produce link
> failures anyway, presumably through misguided heroic efforts.) With
> static libraries, you have to resolve symbols after they are used
> because only the necessary objects are pulled in at link time.
>
> No problem, you say, we'll just link in -lsvn_subr -lsvn_delta
> -lsvn_subr? That doesn't play nice with modern libtool. In an effort
> to avoid the "three million -lz" problem, modern libtool collapses
> redundant library dependencies, under the assumption (perfectly valid
> in
> ~100% of all real-world packages) that there are no circular
> dependencies in the mix. There is a command-line option to prevent
> this
> problem, but I don't believe there's a way to tell that a particular
> pair of libraries depend on each other.

well, in that case, if it could potentially be a problem, we don't
*have* to use svn_delta_default_editor, we can just as easily declare
the editor structure statically in cancel.c and return a pointer to it.
  any objections to that?

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 18 02:33:00 2003

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.