svn trunk doesn't build again

[Ganesan Rajagopal]

Sorry to be replying to my own mail!

>>>>> I <rganesan at users.sourceforge.net> wrote:

> You should be able to able to count on this magic as long as
> <library>_LIBADD variable is properly set. So why did this break for me,
> even after I did a "make distclean"? *scratches head*.

> I'll dig deeper and see if debian libtool is messing something up.

Okay, I have it figured, it's a long post but is very important to an
application like gnucash which has a large number of shared library
dependencies. The patch is required after all. 

<library>_LIBADD variable is sufficient to handle dependencies from that
library to another library for symbol lookup. However, in this case
test_gnc_recurrence and test_gnc_dialog are directly referring to a symbol
in libgncmod-engine i.e. the symbol is required by the test programs
themselves rather than because libgncmod-gnome-utils referred to it. So, the
explicity dependency is required for the linking step.

Now, the reason why this worked for you and not in my specific setup is
Debian specific. libtool normally picks up all libraries for linking by
going through dependency_libs variable of all dependent .la files
recursively. This duplicates library dependencies multiple times which not
only slows down the linking step but is in fact plain wrong. 

Consider, libtool links binary B which depends on libA. libA in turn depends
on libB.  Normally, libtool will put a dependency from binary B to libA as
well as libB. Now imagine libA was updated (without affecting it's external
interface) to no longer depend on libB. binaryB will continue to have an
unnecessary dependency on libB because it was explicitly linked to libB. If B
only depends on libA this problem doesn't arise.

So, Debian used a patched version of libtool fixing this problem (the
problem may also fixed in a upstream libtool, I don't know). Let me
summarize and answer your question on when you can depend on libtool magic.

If libB is referring to a symbol X in libA, you should declare this
dependency in libB_LIBADD. Binary B (an application or a library) linking to
libB do not need to declare a dependency on libA. Shared library magic will
take care of this. However, if B which links to libB directly references
symbol X, it _must_ explicitly list a dependency on libA.

Ganesan

-- 
Ganesan Rajagopal