Ports 104877 causing big problems

Jean-Yves Lefort jylefort at FreeBSD.org
Sat Mar 10 15:44:00 UTC 2007


On Sat, 10 Mar 2007 06:42:31 -0800
Ade Lovett <ade at FreeBSD.org> wrote:

> On Mar 10, 2007, at 05:45 , Jean-Yves Lefort wrote:
> > Repeatedly read the PR until you understand it. Pay attention to the
> > provided objdump diff, and to the fact that the patch modifies the
> > link_all_deplibs variable. Understand what that variable
> > does. Understand why it should be set to "no" rather than to
> > "unknown".
>
> There is no empirical evidence in the PR.
>
> Statement #1: "This slows down the linking considerably"
> This one should be easy enough to prove.  Providing timings.  Pay
> particular attention to the relative timing of the final link-loader
> step compared with the time taken to register all dependencies as
> part of the pkg_install process.

Prove it to yourself if you want.

> Statement #2: "... creates a direct dependency between a library down
> the tree and a leaf program"
> Incorrect.  Take three libraries; A, B, and C.  A depends on B.  B
> depends on C.  In order to ensure deterministic behavior in the event
> of 'C' being upgraded, *all* ports depending on it should also be
> rebuilt.  Thus, if something relatively low level like libpng is
> updated, then to guarantee at least deterministic failure modes,
> everything that depends on libpng should also be rebuilt (either
> manually, or via portupgrade/portmaster, both of which have flags to
> make this an easy process).

A does not reference C. There is no reason to rebuild A. This is
called encapsulation. You don't need to rebuild your whole system when
libpng is updated. It's relatively easy, yet it's entirely useless and
going to take one day or two.

> Statement #3: "The attached patch fixes the problem."
> Unknown.  There are no comparative timings for the link-loader stage
> (statement 1), and merely obfuscates the dependency issue (statement
> 2), particularly given that there are *two* dependency chains being
> discussed, the one inherent to .la files, and the one provided by the
> pkg_* tools.

Unknown to you, because you don't understand the problem. The problem
is that link_all_deplibs is set to unknown, and libtool therefore
assumes that the system does not support library dependencies. It then
proceeds by recursively linking the entire dependency graph into a
program or library, not just the direct dependencies of that program
or library.

--
Jean-Yves Lefort

jylefort at FreeBSD.org
http://lefort.be.eu.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20070310/36fa9cd4/attachment.pgp


More information about the freebsd-ports mailing list