Re: Fwd: New datasource implementation

[Guy Harris <guy () alum mit edu>]

On Jan 3, 2012, at 1:23 AM, David Laight wrote:

> > On all modern UN*Xes, as far as I know, a dynamic library can 
> > be linked with another dynamic library, and if a program is 
> > explicitly linked with the first of those libraries, but 
> > *not* explicitly linked with the second of those libraries, 
> > the program will still work - the run-time linker will see 
> > that the first library requires the second library and will 
> > load and bind it in at run-time.
>
> The gnu/linux folks have recently changed the behaviour
> of gld (probably contrary to the elf specification, but
> they tend not to care about standards)

I either no longer have my old dead-tree SVR4 ABI documents or have them buried in a box somewhere that's probably in 
storage, but the version at

        http://www.sco.com/developers/devspecs/gabi41.pdf

says

        Shared Object Dependencies

        When the link editor processes an archive library, it extracts library members and copies them into the output 
object file. These statically linked services are available during execution without involving the dynamic linker. 
Shared objects also provide services, and the dynamic linker must attach the proper shared object files to the process 
image for execution.

        When the dynamic linker creates the memory segments for an object file, the dependencies (recorded in DT_NEEDED 
entries of the dynamic structure) tell what shared objects are needed to supply the program’s services. By repeatedly 
con- necting referenced shared objects and their dependencies, the dynamic linker builds a complete process image. When 
resolving symbolic references, the dynamic linker examines the symbol tables with a breadth-first search. That is, it 
first looks at the symbol table of the executable program itself, then at the symbol tables of the DT_NEEDED entries 
(in order), then at the second level DT_NEEDED entries, and so on. Shared object files must be readable by the process; 
other per- missions are not required.

That doesn't seem to specify anything about what the link editor, as opposed to the dynamic linker, must do about 
DT_NEEDED structures.

> so that linker
> will not assume that libraries referenced by DT_NEEDED
> entries in other libraries have their symbols made available
> to teh main program.

Do you have any references for this, so I can see exactly what it means?

If it just means that if you build an executable image (or shared library), linking it with library A, and library A is 
a shared that is linked with library B, and if the executable image is *not* linked with library B when you build it, 
if the image refers to routines in library B those references will *not* be treated as resolved by virtue of library B 
being dragged in by library B, that doesn't appear to break the scenario I describe.

> This breaks many things!

Does it, in particular, break the scenario I describe?

> What happens at run time depends on the dynamic linker.

If, with some dynamic linker, it means that if an executable image is linked with library A, and is not linked with 
library B and does not use anything from library B, and library A is linked with library B and does use things from 
library B, then, when that executable image is run, symbols from library B are not available to the main program, that 
doesn't break my scenario, and I'm not sure what useful things it would break.

If, with some dynamic linker, it means that if an executable image is linked with libraries A and B, and does use 
thinks from library B, and library A is linked with library B and does use things from library B, then, when that 
executable image is run, symbols from library B are not available to the main program, that would be Very Bad and Very 
Stupid.  Would there be any dynamic linkers that work that way?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.