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

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

On Mon, Oct 14, 2013 at 15:10:47 +0200, Martin Husemann wrote:

> On Mon, Oct 14, 2013 at 04:59:34PM +0400, Valery Ushakov wrote:
> > 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.
> 
> You quoted:
> 
> | If a shared object has dependencies on other shared objects, these
> | dependencies can also be processed.  This processing occurs after
> | all command line input files have been processed, to complete the
> | symbol resolution process.  However, the shared object names are not
> | recorded as dependencies in the output file image being generated.
> 
> I read this as: the indirect symbols are resolved but no DT_NEEDED
> entries generated.

And then I wrote:

| Hmm, using http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
| example on Solaris 11:
| 
| $ gcc --verbose -o foo1 foo1.o -L. foo2.so
| [...]
| ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2324
| Undefined   first referenced
|  symbol         in file
| foo         foo1.o  (symbol belongs to implicit dependency ./foo3.so)
| ld: fatal: symbol referencing errors. No output written to foo1

So the symbol is NOT resolved.

Does OpenSolaris use gnu binutils, btw?  I wonder why pkgsrc hasn't
hit these problems on Solaris as well.


> > If we fix link commands to provide explicit dependencies, that will
> > work with both old behaviour and new behaviour, won't it?
> 
> Yes, after fixing the fallout (which I expected to be bigger).

-uwe