[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 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).
Main Index |
Thread Index |