svn trunk doesn't build again

[Peter O'Gorman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Shoemaker wrote:
| 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.
|

This issue is specific to debian libtool. If Ganesan installs a more recent
version of gnu libtool from ftp.gnu.org he'll not have a problem. Since, for
an actual release, the libtool used is the one on the release manager's
system, I think you should ask developers to use a gnu version.

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ9FuhbiDAg3OZTLPAQIbGwP/fXmU/oZSktQCu7vVepdujesYwC0omIpk
Hg9wxl2bLdqme2hRYPHu/YBNQmiszBdRZD51c1ypFEzaaqq8uzlmljumSp1f2fyR
HtKnrU+5RWxqp8WV1pNUoLKVb3lQ1LxA2nt3UE05jXG20QHhvJeCphhRxLmMYzu5
kS22Q+nwnTY=
=LPGp
-----END PGP SIGNATURE-----