GNU bug report logs - #13920
link_all_deps and indirect dependencies

Previous Next

Package: libtool;

Reported by: Дилян Палаузов <dilyan.palauzov <at> aegee.org>

Date: Sun, 10 Mar 2013 22:12:01 UTC

Severity: normal

To reply to this bug, email your comments to 13920 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-libtool <at> gnu.org:
bug#13920; Package libtool. (Sun, 10 Mar 2013 22:12:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Дилян Палаузов <dilyan.palauzov <at> aegee.org>:
New bug report received and forwarded. Copy sent to bug-libtool <at> gnu.org. (Sun, 10 Mar 2013 22:12:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Дилян Палаузов
	<dilyan.palauzov <at> aegee.org>
To: bug-libtool <at> gnu.org
Subject: link_all_deps and indirect dependencies
Date: Sun, 10 Mar 2013 23:10:15 +0100
Hello,

in my project, I have program A that dynamically links with library B 
(library B is mentioned as DT_NEEDED in program A), and library B 
dynamically links with library C (library C is mentioned as DT_NEEDED in 
library B, and under dependency_libs in libraryB.la).

--> If I want to use a function from library C in program A, am I 
supposed to list (in Makefile.am) that program A depends on library C, 
or can I rely on the fact, that program A loads library B and library B 
loads library C, thus it is not necessary to link explicitly program A 
with library C?

Under Debian, libtool is patched to have link_all_deplibs=no, on other 
systems link_all_deplibs is unknown/yes.  When link_all_deplibs is yes, 
I do not have to link program A explicitly with library C; when 
link_all_deplibs is no, I have to link explicitly.

Program A, library B and library C are in the control of the same 
person, so the dependency on libC in libB is ensured.

According to the Debian maintainer of the libtool package, 
bugs.debian.org/cgi-bin/bugreport.cgi?bug=702737 , libtool's 
documentation shall state (or states, but I don't find where), that 
program A must explicitly link with library C.

Thanks in advance for your feedback
  Дилян




Information forwarded to bug-libtool <at> gnu.org:
bug#13920; Package libtool. (Mon, 11 Mar 2013 05:36:02 GMT) Full text and rfc822 format available.

Message #8 received at 13920 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> vaughan.pe>
To: Дилян Палаузов
	<dilyan.palauzov <at> aegee.org>
Cc: 13920 <at> debbugs.gnu.org
Subject: Re: bug#13920: link_all_deps and indirect dependencies
Date: Mon, 11 Mar 2013 12:34:42 +0700
On 11 Mar 2013, at 05:10, Дилян Палаузов <dilyan.palauzov <at> aegee.org> wrote:
> Hello,

Hi,

> in my project, I have program A that dynamically links with library B (library B is mentioned as DT_NEEDED in program A), and library B dynamically links with library C (library C is mentioned as DT_NEEDED in library B, and under dependency_libs in libraryB.la).
> 
> --> If I want to use a function from library C in program A, am I supposed to list (in Makefile.am) that program A depends on library C, or can I rely on the fact, that program A loads library B and library B loads library C, thus it is not necessary to link explicitly program A with library C?

Best practice dictates that you should list all of the libraries whose APIs you use.  So if you use an API from C in A, then A has an explicit dependency on C.

Libtool doesn't enforce this though, so if you prefer to be sloppy about dependencies it will still link correctly.


> Under Debian, libtool is patched to have link_all_deplibs=no, on other systems link_all_deplibs is unknown/yes.  When link_all_deplibs is yes, I do not have to link program A explicitly with library C; when link_all_deplibs is no, I have to link explicitly.

Debian have broken one of the core features of libtool with that patch.  If you prefer to use the debian libtool, then you will need to list all your deplibs explicitly, since they have turned off the feature that tracks them for you. Alternatively, you can install a fully working libtool from gnu.org.

Debian and GNU disagree about the benefits of link_all_deplibs, and we have agreed to disagree.  There's no need to dig up the old arguments about the relative benefits of either approach, where both sides are already happy to co-exist peacefully :)

> Program A, library B and library C are in the control of the same person, so the dependency on libC in libB is ensured.
> 
> According to the Debian maintainer of the libtool package, bugs.debian.org/cgi-bin/bugreport.cgi?bug=702737 , libtool's documentation shall state (or states, but I don't find where), that program A must explicitly link with library C.

Agreed.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)





Information forwarded to bug-libtool <at> gnu.org:
bug#13920; Package libtool. (Tue, 02 Apr 2013 20:08:02 GMT) Full text and rfc822 format available.

Message #11 received at 13920 <at> debbugs.gnu.org (full text, mbox):

From: Дилян Палаузов
	<dilyan.palauzov <at> aegee.org>
To: 13920 <at> debbugs.gnu.org, 702737 <at> bugs.debian.org
Subject: documentning link_all_deplibs on Debian
Date: Tue, 02 Apr 2013 22:04:09 +0200
Hello,

In regards of libtool bug #13920 and debian bug #702737 I kindly ask you 
to update the documentation of libtool in aspect of link_all_deplibs, 
with something like the text below.  I consider this as essential, as it 
would have saved me quite some (from my free) time investigating why the 
linking on Debian works differently/not according to the documentation. 
 A proper documentation of link_all_deplibs on different systems, will 
safe the time of other developers investigating the same issue.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index c06ddaa..ec0d926 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -6938,6 +6938,9 @@ the file name that the linker finds when given 
@option{-l <at> var{name}}.
 Whether libtool must link a program against all its dependency libraries.
 Set to @samp{yes} or @samp{no}.  Default is @samp{unknown}, which is
 a synonym for @samp{yes}.
+
+On Debian and Ubuntu systems the default is @samp{no}.  As a side effect,
+transitive dependencies which rely on @samp{yes} will break.
 @end defvar

 @defvar link_static_flag




This bug report was last modified 12 years and 131 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.