svn trunk doesn't build again

[Chris Shoemaker]

On Fri, Jan 20, 2006 at 09:46:59PM +0530, Ganesan Rajagopal wrote:
> 
> 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.

Thanks for the research and clear explanation.  Just to restate in my
own words: Basically, some versions of libtool don't recursively link
dependent libraries.  Good to know.

To any users of such a libtool: Please keep an eye out for this and
submit patches as needed.  It's not easy to test for otherwise.

-chris