SVN compile error

Thomas Bushnell BSG tb at becket.net
Wed May 17 18:13:11 EDT 2006


Derek Atkins <warlord at MIT.EDU> writes:

> Quoting Thomas Bushnell BSG <tb at becket.net>:
>
>> What I mean is that *sometimes* they are spurious, not that they
>> always are.
>
> Yeah, but libtool can't tell when they are from when they aren't.
> Standard libtool errs in one direction.  Debian libtool errs on the
> other.  In this case Debian Libtool causes the compilation to fail,
> because there was an assumption that libtool would keep track of
> the dependencies for us.  Debian broke that assumption, which is
> why it's failing now.

libtool never kept track of dependencies, actually. :)

libtool actually can tell.  Debian's version does not omit any needed
dependencies, in the sense that Debian's version never fails to
declare a dependency that ought to be there.  "Ought to be there"
meaning that A should depend on B when a change in B could necessitate
a recompile of A.

In the normal case, we have a program P, which links against library
L.  P depends on L.  Also, L links against library Q.  P does not use
anything from library Q directly; the API of library Q does not affect
P at all.  But standard libtool goes ahead and declares that P depends
on Q.

Programs like gnucash have been relying on this behavior in cases
where P *does* use the API of Q.  You are correct that if you don't
declare that P uses the API of Q, then there is no simple way to
automatically figure out when P actually needs Q and when it doesn't.

But how about this instead: just have P actually declare which
libraries it uses and link against them?  After all, nobody else but P
has the facts necessary to do that.

I would be happy to help do this if nobody else in gnucash land wants
to, but the current build system is so arcane that I can't figure it
out on my own, so I would need help.  (I understand that this has been
a problem for some time, and that the current crop of developers are
not really responsible for the build system's arcanity.)

This is a serious problem in any system in which P, L, and Q are
packaged separately.  Debian has been confronted with cases where
hundreds of packages contained spurious dependencies on packages,
which all then require coordinated recompilation against the new
version of Q, all completely unnecessarily, and costing weeks and
weeks of work.  

Thomas


More information about the gnucash-devel mailing list