Re: binutils-2.22: ld and --copy-dt-needed-entries

On Tue, Dec 6, 2011 at 23:41, Andriy Gapon <avg_at_freebsd.org> 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.  With --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.  With the default
>>>> setting however the searching of dynamic libraries that follow it
>>>> will stop with the dynamic library itself.  No 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.  Eventually all upstreams of our ports will have to deal with
> this.  So far I've encountered only one problematic port (gegl) that links a
> binary with -lglib-2.0 expecting that a required -liconv dependency would be
> automatically picked up via DT_NEEDED.  libglib-2.0.so indeed has a DT_NEEDED
> entry for libiconv.so.  But this dependency is not explicitly advertised 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.  I 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)

-- 
Andrew W. Nosenko <andrew.w.nosenko_at_gmail.com>