On Fri, Jan 20, 2006 at 09:46:59PM +0530, Ganesan Rajagopal wrote: > > Sorry to be replying to my own mail! > > >>>>> I <[EMAIL PROTECTED]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
