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

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

On Sun, Oct 13, 2013 at 14:54:15 +0100, David Laight wrote:

> On Sun, Oct 13, 2013 at 01:23:15AM +0400, Valery Ushakov wrote:
>
> > Linker and Libraries Guide / Part No: 819-0690-10 / November 2011,
> > page 37:
> > 
> > | 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.
> > 
> > So pkgsrc already should be handling the new way to work on Solaris,
> > shouldn't it?
> 
> Nope: Solaris is using the 'traditional' behaviour where a program can
> reference symbols in dependant libraries but only ends up with a
> single DT_NEEDED entry.

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


> IIRC this the way the dynamic linkey works (even on Linux).
>
> The gnu_ld have f*cked this up completely.
> 
> It seems to me that they should have added 2 new type of DT_NEEDED
> to shared libraries, the first would hide the symbols from the main
> program, the second (actually less useful) would generate a normal
> DT_NEEDED entry in the main program.
> 
> Then the dynamic linker could be modified to behaive the same way.
> (ie put some of the symbols into a separate namespace).

-uwe