-----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 <[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. |
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----- _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
