Re: "Fixing" new ld(1) DT_NEEDED handling

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Mon, Oct 14, 2013 at 08:45:34 +0200, Martin Husemann wrote:

> You guys have lost me - let me try to summarize and please correct me:
> 
> AFAIU the solaris linker behaviour (as quoted by uwe) is the only sane
> one.
[...]
> Unfortunately you can not get the "resolve symbol, but do not copy
> NEEDED" behaviour from gnu ld with any combination of options, and you
> could not get it from the old version of binutils either. This still
> leaves us with two IMHO broken behaviours as only short term options.

I'm still confused.  The observed beahviour (see one of my previous
mails) is that solaris ld does NOT resolve symbols from implicit
dependencies.  I.e. the new gnu ld behaviour matches solaris ld.


> I do not see any real harm done with reverting the default. 

Do you mean that the final result will be the old behaviour?  Or the
new behaviour?


> What could possibly fail if third party software provides all -l
> args but we would copy NEEDED entries from indirect references?

If we fix link commands to provide explicit dependencies, that will
work with both old behaviour and new behaviour, won't it?  With the
old behaviour the NEEDED are copied from direct dependencies by ld, so
adding some of them as explicit dependencies doesn't change the set of
NEEDED recorded in the program and the link step still works and
produces the same binary as before.  With the new behaviour adding
those explicit dependencies will make the link command work where
previously it would fail because of unresolved symbols.


-uwe