binutils-2.22: ld and --copy-dt-needed-entries
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. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: binutils-2.22: ld and --copy-dt-needed-entries
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? -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: binutils-2.22: ld and --copy-dt-needed-entries
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.
--
Andriy Gapon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: binutils-2.22: ld and --copy-dt-needed-entries
On Tue, Dec 6, 2011 at 23:41, Andriy Gapon a...@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.nose...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
