tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On Sun, Oct 13, 2013 at 07:54:14PM +0000, David Holland wrote:
> Given the proclivities of the dynamic linker, it's very dangerous for
> the dynamic linker and the static linker to use different name
> resolution rules and/or different scoping.
> It should be possible to make the dynamic linker match the new static
> linkage rules; however, this is likely to break old binaries...

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

With that (Solaris ld) behaviour, our ld.elf_so behaves sane too, so no
changes there needed.

Creating new "hidden" NEEDED entries would make it possible to catch
wrong linker command lines, like what apparently the binutils folks
tried to do with their changed default. However, this would be a
(trivial) change in object format and require runtime linker changes.

I would be happy if we could get the Solaris linker behaviour. The hidden
needed extension might be something to evaluate closer and, if it shows real
advantages, get discussed upstream.

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 do not see any real harm done with reverting the default. What could
possibly fail if third party software provides all -l args but we would
copy NEEDED entries from indirect references?


Home | Main Index | Thread Index | Old Index