From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 23:26:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9BA6106564A; Tue, 6 Dec 2011 23:26:23 +0000 (UTC) (envelope-from andrew.w.nosenko@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AACD88FC0A; Tue, 6 Dec 2011 23:26:22 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so7517740wgb.31 for ; Tue, 06 Dec 2011 15:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YUWRSI2uetlwVZo3nckElsgGbVYeL/ZXcQ08olGiAKg=; b=r4/lR72VQHpU2FC0x6+Fpd6XaxGUVPITmKdXhQd/xiZ0JGfsgiFtkcuuOBJDyFsWoH ucDrNT7oJDXxMeZvEi6KChFuNHU6ugZOxcG+jhMo6eaULejwFuumIBZuhRmPg8MpZZ7f tw0FbC5DeLeNtaWZ8HjJRGzEropOmYftCysCc= MIME-Version: 1.0 Received: by 10.227.206.6 with SMTP id fs6mr3436748wbb.20.1323212337084; Tue, 06 Dec 2011 14:58:57 -0800 (PST) Received: by 10.227.181.74 with HTTP; Tue, 6 Dec 2011 14:58:57 -0800 (PST) In-Reply-To: <4EDE8C0E.7050806@FreeBSD.org> References: <4EDE474C.8090600@FreeBSD.org> <4EDE8816.7030505@FreeBSD.org> <4EDE8C0E.7050806@FreeBSD.org> Date: Wed, 7 Dec 2011 00:58:57 +0200 Message-ID: From: "Andrew W. Nosenko" To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 07 Dec 2011 02:01:24 +0000 Cc: FreeBSD current , Martin Matuska , FreeBSD Ports Subject: Re: binutils-2.22: ld and --copy-dt-needed-entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 23:26:23 -0000 On Tue, Dec 6, 2011 at 23:41, Andriy Gapon wrote: > on 06/12/2011 23:24 Martin Matuska said the following: >> On 6.12.2011 17:48, Andriy Gapon wrote: >>> Just for your information. >>> It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-= entries >>> behavior, and so explicit --copy-dt-needed-entries is now needed where = the >>> previous default behavior is relied upon. >>> >>> A short excerpt from the man page for your convenience: >>> >>>> This option also has an effect on the resolution of symbols in >>>> dynamic libraries. =A0With --copy-dt-needed-entries dynamic libraries >>>> mentioned on the command line will be recursively searched, >>>> following their DT_NEEDED tags to other libraries, in order to >>>> resolve symbols required by the output binary. =A0With the default >>>> setting however the searching of dynamic libraries that follow it >>>> will stop with the dynamic library itself. =A0No DT_NEEDED links will >>>> be traversed to resolve symbols. >> What do we do with this? >> We can go back, patch to behave as before or to continue. >> Are there any serious complaints? > > I am not sure. =A0Eventually all upstreams of our ports will have to deal= with > this. =A0So far I've encountered only one problematic port (gegl) that li= nks a > binary with -lglib-2.0 expecting that a required -liconv dependency would= be > automatically picked up via DT_NEEDED. =A0libglib-2.0.so indeed has a DT_= NEEDED > entry for libiconv.so. =A0But this dependency is not explicitly advertise= d via > pkg-config metadata: > $ fgrep -i Libs /usr/local/libdata/pkgconfig/glib-2.0.pc > Libs: -L${libdir} -lglib-2.0 > Libs.private: -liconv > > So there could be other issues related to this in the future. > Perhaps this is actually an issue with glib, maybe it should have -liconv= in > Libs. =A0I am not really knowledgeable about his stuff. As far, as I understand the http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html , https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition , http://old.nabble.com/Make-no-copy-dt-needed-default--td32272377.html , correctly 1. upstreams (e.g. Glib) had a pretty much time for test this change. 2. If I just use Glib (for example), then all Glib's iconv-related stuffs will continue to work, I don't need to explicitly add -liconv. All that fail if I use iconv_open() (for example) directly and (bypassing Glib) and rely on Glib to load libiconv as side-effect. Of courcse, it would be quite wrong from my side because existence of libconv as an Glib charset conversion engine is an implementation detail that may change at the some day or just because of different configuration options. Just like GnuTLS swtiched from libgcrypt to libnettle. 3. Of course, something may fail, but I would not to expect a big amount of failures (due to the fact that major Linux distros already there) --=20 Andrew W. Nosenko