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.
